我们用 jmeter 做性能测试，必须需要学会分析测试报告。但是初学者常常因为对概念的不清晰而被测试报告带到沟里去。
分析响应时间全用平均值
响应时间不和吞吐量挂钩
响应时间和吞吐量不和成功率挂钩
。。。。。
平均值为什么不靠谱？相信大家读新闻的时候经常可以看到，平均工资，平均房价，平均支出，等等字眼，你就知道为什么平均值不靠谱了。
（这些都是数学游戏）
我们做性能测试时，得到的结果数据不会总是一样的，而是波动的。
如果算平均值就会出现这样的情况：测试了 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
系统的性能如果只看吞吐量，不看响应时间是没有意义的
我的系统 tps 可以达到 10000，但是响应时间已经到了 20 秒钟，这样的系统已经不可用了，吞吐量也是没有意义的。
当负载上升的时候，系统会逐渐变的不稳定，响应时间也会变得越来越慢，波动越来越大，而吞吐率却开始下降，包括 CPU 的使用率情况也会如此。
所以，当系统变得不稳定的时候，吞吐量已经没有意义了。
所以，吞吐量的值必需配合响应时间来看。例如：TP99 小于 100ms 的时候，系统可以承载的最大并发数是 1000。
应该不难理解，如果请求都是错误的，还做什么性能测试。
比如，我说我的系统并发可以达到 10 万，但是失败率是 50%，那么这 10 万的并发完全就是一个笑话。
性能测试的失败率的容忍是非常低的。对于一些关键系统，成功率必须在 100%
