Jmeter性能测试常用到的图

主要使用查看结果树，聚合报告。

查看结果树：要勾选‘仅日志错误’，只显示错误日志。

 

测试用例，尽可能保持简单。不能加定时器，除非要加集合点，可以使用Synchronizing Timer。

控制器：可以使用简单控制器（放有序执行的测试用例），随机顺序控制器（放无序执行的测试用例），其他控制器不要用。尽量少用For each，循环控制器，因为并发数不好控制,避免对并发数产生影响。

前置、后置处理器：尽量不要使用。尤其不能使用BeanShell。除非必须要使用。正则提取器不会产生太大的性能影响。

断言：尽量不要用断言，要用的话，推荐使用响应断言，不推荐用BeanShell断言。

 

聚合报告：主要看Average(平均响应时间，保证尽可能短), Error（保证不能出错）, Throughput（吞吐量，是否达到期望值，也就是TPS-每秒处理的事务数）。

吞吐量的变化在聚合报告中看不出来，要用其他插件。聚合报告中最终的吞吐量是不准的。要用后面讲到的集中图表来分析。

错误率也是非常重要，一旦出现错误了，说明服务器出现压力了，瓶颈了，需要进行分析了。（当然首先要保证功能测试没有错误，功能测试没有问题，才可以进行性能测试）。功能测试没有错误了，做性能测试Error不应该出现。如果出现了，说明服务器在高并发的情况下，出现压力了，达到瓶颈了。比如说连接超时了，拒绝连接了。

如果没有插件，主要看结果树，聚合报告，做以上这些就够了。

线程：

线程组

设置线程启动，增加，减少，停止的规则。增加/减少线程尽量不要太快。就是图中的曲线坡度不要陡，才能保证性能测试的数据比较准确。 

性能测试用到的图：

 

 

http://jmeter-plugins.org/wiki/

 

Active Threads Over time

 

线程数的变化，X轴是执行时间，Y轴是线程数，和stepping thread group 中配置的线程数图标类似。

Transactions Throughput vs Threads

 

 

Transactions Throughput vs Threads

吞吐量的评估值，X轴是线程数，评估值是不准的。线程数急剧变化的时候（比如线程数108到120时间，有个突然上升到4000的点，是不准的），吞吐量评估值都是不太准的。

50到70个线程数时，吞吐量是比较准的。

65个线程数时，吞吐量最大：

结合Active Threads Over time, 知道65个线程数大概时间是在40到43秒之间：

 

 

Transactions per Second

 

每秒的事务量。这是实际的吞吐量。如果写测试报告，要写吞吐量的话，要从多个维度分析。主要看Transactions per Second，不能只看聚合报告的最终吞吐量。（这是不准的）

 

这和通过Transactions Throughput vs Threads和Active Threads Over time2者结合分析出来的时间是吻合的（40到43秒，吞吐量最大）。

 

 是因为这段时间线程数增加比较快

 

Connection Times Over Time

连接时间，一般在几毫秒，不超过5毫秒是理想的。尽量不能让连接时间达到几十毫秒，这是网络问题太大了。这个图是用来排除网络问题的。比如某个时间点吞吐量下降厉害了，要去看这个时间点的连接时间是否正常，如果连接时间很长，就是网络问题造成的，不能判断为性能问题。

Response Latencies  Over Time/Response Times Over Time

响应延迟时间和响应时间基本上是一样的。

响应延迟时间：发起请求到接口开始响应的时间。

  

 

如果Transactions per Second每间隔一定时间，就到达一个顶点（这个顶点），并且每次到达一个顶点的时间都是在线程数增加的时候（结合Active Threads Over time），说明线程数还能再增加，继续增加测试的线程数：