你真的会使用Jmeter吗（三）聚合报告Aggregated report中的秘密

       用Jmeter做性能测试时，如何阅读Jmeter聚合报告是一个最基本问题。聚合报告中的各项参数各种代表什么含义，以及它们之间又有什么样的关系？大部分人只是笼统的了解一点，而我现在就聊一聊聚合报告中那些不为人知的秘密。

正文

       先来一张聚合报告的图

       上图中执行策略为100 * 1 * 100即100个线程1秒内启动循环100次：

1. #Sample代表样本总数：线程中有两个请求获取token和执行业务逻辑，业务逻辑执行了10000次没什么问题，获取token执行了100是因为用了 Once Only Controller每个线程只执行1次共100次。
2. Average：平均响应时间，单位毫秒。
3. Median：响应时间中位数，单位毫秒。
4. 90%line：90%的用户响应时间，以图为例90%用户响应时间内小于等于1743ms。
5. 95%line：95%的用户响应时间，以图为例95%用户响应时间内小于等于2015ms。
6. 95%line：99%的用户响应时间，以图为例90%用户响应时间内小于等于3321ms。
7. Min:最小的用户响应时间，单位毫秒。
8. Maximum：最大的用户响应时间，单位毫秒。
9. Error%：错误率
10. Throughput ：吞吐率，单位 个/s。
11. Received KB/sec:每秒接收字节数。
12. Send KB/sec:每秒发送字节数。

       上一节我埋了个坑，这节我们就从吞吐率与并发用户数的关系开始讲起。关系图如下。

       从上图我们可以看到在并发数到达50 之前，吞吐率会随着并发数的提高而提高。为什么会这样呢？因为当先环境下的最大吞吐率为100/s，在并发数小于50的时候，Jmeter抛出的事务请求小于100/s,所以并发数提高Jmeter抛出的事务请求也在提高，因为没有达到最大达吞吐率所以吞吐率也会提高。
       在并发数达到50后，因为吞吐率已经达到最大，所以吞吐率不会在变，但是随着并发数的不断增加，平均响应时间也会增加，而并发数50之前，平均响应时间是趋近于一个数的，因为消费>生产，每一个事物请求的响应时间就是处理该事物的时间。在并发数50之后，生产>消费，每一个事物请求的响应时间就是处理该事物的时间+等待被处理的时间。由于并发数越高，等待的队列就越长（这里是一种比喻），所以响应时间就会越长。
我们再来看一张图

       这张图与本文第一张图是同一脚本在不同时间执行的结果。我们可以很容易看到这两者之间的区别，下面的图的字节吞吐量更高（网络更好），而吞吐率也更高，这也可以作为上一节的补充，网络带宽影响吞吐量，所以一定要看服务器上的一些指标，如果你服务器上的资源使用率一直上不去，是不是可以考虑一下测试环境带宽的原因呢？下一节我将聊聊性能测试的一些指标。

总结

1. 在不同并发数下测试系统的性能时，吞吐率会先增加后出现瓶颈并趋于稳定。
2. 吞吐率瓶颈前，吞吐率虽并发数增加而增加，平均响应时间不会有太大差别。
3. 吞吐率瓶颈后，吞吐率趋于稳定，平均响应时间会随并发数增加而增加。
4. 网络带宽影响吞吐率，同一脚本带宽越高，吞吐率瓶颈越高，当然是在服务器资源使用率未满的情况。
5. 同一网络带宽下，请求的大小影响吞吐率。如一个5K的请求和一个1000K的请求。

       题外话，在测试过程中测出的一些我们通常认为是异常的数据，一定不要放过，因为它一定是我们系统或者我们测试环节中某些因素导致的，于公于私都值得深究，求甚解！！！如有疑问，请评论留言，谢谢。