jmeter分析性能报告时的误区

概述

咱们用jmeter作性能测试，必然须要学会分析测试报告。可是初学者经常由于对概念的不清晰，最后被测试报告带到沟里去。

 

常见的误区

• 分析响应时间全用平均值
• 响应时间不和吞吐量挂钩
• 响应时间和吞吐量不和成功率挂钩

。。。。。

 

平均值特别不靠谱

平均值为何不靠谱？相信你们读新闻的时候常常能够看到，平均工资，平均房价，平均支出，等等字眼，你就知道为何平均值不靠谱了。

（这些都是数学游戏）

性能测试也同样，平均数也是不靠谱，推荐一篇详细的文章《Why Averages Suck and Percentiles are Great》

咱们作性能测试时，获得的结果数据不会老是同样的，而是波动的。

若是算平均值就会出现这样的状况：测试了10次，有9次是1ms，而有1次是10s，那么平均数据就是1s。

很明显，这彻底不能反应性能测试的实际状况，由于那个10s的请求就是一个不正常的值。

另外，中位数（Median）可能会比平均数要稍微靠谱一些，中位数的意就是把将一组数据按大小顺序排列，处在最中间位置的一个数叫作这组数据的中位数 ，这意味着有50%的数据低于或高于这个中位数。

最为正确的统计作法是用百分比分布统计。TP50的意思是50%的响应时间都小于某个值，TP90表示90%的响应时间小于某个值。

咱们有一组数据：[ 10ms,  1s, 200ms, 100ms]，咱们把其从小到大排个序：[10ms, 100ms, 200ms, 1s]。

因而咱们知道，TP50，就是50%的请求ceil(4*0.5)=2时间是小于100ms的，TP90就是90%的请求ceil(4*0.9)=4时间小于1s。

因而：TP50就是100ms，TP90就是1s

所以，一般严格一点的响应时间要求是这样的：99%的请求必须小于XXms

 

响应时间务必和吞吐量（Thoughput）挂钩

系统的性能若是只看吞吐量，不看响应时间是没有意义的。

个人系统tps能够达到10000，可是响应时间已经到了20秒钟，这样的系统已经不可用了，吞吐量也是没有意义的。

当负载上升的时候，系统会逐渐变的不稳定，响应时间也会变得愈来愈慢，波动愈来愈大，而吞吐率却开始降低，包括CPU的使用率状况也会如此。

因此，当系统变得不稳定的时候，吞吐量已经没有意义了。

 

因此，吞吐量的值必需配合响应时间来看。例如：TP99小于100ms的时候，系统能够承载的最大并发数是1000。

 

响应时间吞吐量和成功率要挂钩

应该不难理解，若是请求都是错误的，还作什么性能测试。

好比，我说个人系统并发能够达到10万，可是失败率是50%，那么这10万的并发彻底就是一个笑话。

性能测试的失败率的容忍是很是低的。对于一些关键系统，成功率必须在100%