1、jmeter分布式压测怎么配置
修改jmetre.properties文件添加压力机ip端口如果模拟1000个线程请求，有4个压力机（服务器），那么需要将线程数设置为250
2、性能监控命令
top
Vmstat
mpstat
free
iostat 磁盘监控
uptime 平均负载
pidstat -u 5 1 查看哪个进程导致资源占用过高
3、压测tps上不去什么原因？怎么排查
1>压力机本身性能瓶颈
2>网络IO瓶颈
3>中间件（tomcat/nginx/mysql）连接数限制
4>Java线程的阻塞、等待
5>本系统资源的瓶颈（cpu、内存、磁盘、网络等）
6> 其他外部系统响应时间过长，造成本系统的time-wait
4、数据怎么写入influxdb，grafana的exporter和dashboard怎么设计
在jmeter里配置监听器，把influxdb的信息配置成功，运行jmeter查看influxdb是否写入数据
数据源配置：把influxdb信息配置成功
仪表盘创建：信息填好之后选择配置好的数据源，再次执行就能通过图形实时监控了
5、性能测试场景怎么设计？
一般基本的场景包括：基准测试、单交易测试、混合测试、稳定性测试。
其他场景的可选场景：高可用性测试、异常测试等，以及其他的结合各自项目业务的场景。
单交易基准测试，使用压测工具或平台，1个用户或者基准用户数，运行5分钟或者迭代100次。
单交易负载测试，并发用户逐渐递增到预估值情况下，运行10分钟。
混合测试，多种交易设置不同并发用户占比的情况下，运行30分钟。
稳定性测试，选择混合测试支持最大并发用户数的80%，运行2小时。
如果压测工作任务时间允许，可以适当调整压测场景运行时间。
如果要求被测系统支持7*24小时稳定性，稳定性测试运行时间也要跟着做调整。
6、线程死锁怎么定位分析
分析：造成这种现象的原因有很多，可能是网络原因，但测试时用的是局域网，所以不可能是网络的问题。也可能是CPU使用过高导致服务器端负载过大，无法处理客户端的请求导致的，此时去检查应用服务器和数据库服务器的CPU，发现还没有达到60%，所以可以排除资源瓶颈问题（当时的测试场景资源指标是应用服务器CPU不能超过60%，数据库服务器CPU不能超过80%）。因为基准测试和负载测试都是测单个交易，而混合场景是把多个交易放到一起发压，既然是多个交易，就有可能存在死锁问题，而混合场景的测试目的是为了检测是否存在线程死锁和数据库死锁。
死锁是因为多线程访问共享资源，由于访问顺序不当造成的，通常是一个线程锁定了一个资源A，而又想去锁定资源B，在另一个线程中，锁定了资源B，而又想去锁定资源A以完成自身的操作，两个线程都想得到对方的资源，而不愿意释放自己的资源，造成两个线程都在等待，而无法执行的情况。
定位：用JDK自带的命令jstack -pid去查看线程信息，jstack很快就帮我们找到了死锁的位置（在实际运行中，往往dump一次信息，还不足以确认问题，建议多dump几次，如果每次dump都指向同一个问题，那么就可以确定是这个问题导致的线程死锁）
7、内存泄漏和内存溢出区别
内存泄漏：程序使用的空间用完也无法释放，积累下导致内存被占光
内存溢出：要求分配的内存超出了系统可分配的，导致内存溢出
8、高并发下需要注意哪些
- 尽量使用缓存，
- 优化数据库查询，提高查询效率
- 使用服务器集群
9、常见的性能指标有哪些？分别是什么含义？
1>tps：每秒事务量，代表了系统的处理能力，tps越高，性能越好
2>响应时间：从发出请求到接受到系统响应数据所花费的时间，响应时间越短，性能越好
3>吞吐量：网络上行和下行流量的总和，吞吐量是网络瓶颈定位的重要指标
4>错误率：在压测过程中系统出现错误的比例
10、产品就只给一个需求，需求调研的内容都不知道，也没人告诉你，怎么开展性能测试
1>没有任何途径进行需求调研的情况下，可以跳过需求调研，直接开始压测。
2>压测完成后，可以把本次压测数据开会讨论，共同决定是否满足性能需求。
3> 根据行业内的通用指标规范
11、服务器的cpu使用率和load（负载）是什么关系？
1>通常情况下，cpu使用率和load值是正比关系，即cpu使用率越高，load值越高。
2>在一些特殊情况下，也会出现cpu使用率不高，但是load值较高的情况。
12、应用服务器cpu高和数据库服务器cpu高的分析思路是什么？
1>应用服务器的cpu高，先要看tps和响应时间，如果tps比较高，我们认为是正常的cpu消耗；如果tps比较低，那么往往某些代码过于消耗cpu。
2>数据库服务器cpu高，往往是因为sql语句执行效率比较低，可以通过对数据库慢查询是监控，结合执行计划进行分析，是否是相关表没有索引或索引未生效。
347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
