性能测试究竟应该怎么做
》》》推荐阅读《《《
1、
2、
3、
4、
性能测试究竟应该怎么做？——改变你的意识
偶然间看到了阿里中间件 Dubbo的性能测试报告 ，我觉得这份性能测试报告让人觉得做这性能测试的人根本不懂性能测试，我觉得阿里的影响力加上“墙”（网络墙和语言墙），会把大众带沟里去，所以，想写算这篇文章，做一点科普。
首先，这份测试报告里的主要问题如下：
1）用的全是平均值。老实说，平均值是非常不靠谱的。
2）响应时间没有和吞吐量TPS/QPS挂钩。而只是测试了低速率的情况，这是完全错误的。
3）响应时间和吞吐量没有和成功率挂钩。
为什么平均值不靠谱
关于平均值为什么不靠谱，我相信大家读新闻的时候经常可以看到， 平均工资 ， 平均房价 ， 平均支出 ，等等这样的字眼， 你就知道为什么平均值不靠谱了。（这些都是数学游戏，对于理工科的同学来说，天生应该有免疫力）
软件的性能测试也一样，平均数也是不靠谱的，这里可以参看这篇详细的文章《 Why Averages Suck and Percentiles are Great 》，我在这里简单说一下。
我们知道，性能测试时，测试得到的结果数据不总是一样的，而是有高有低的，如果算平均值就会出现这样的情况，假如，测试了10次，有9次是1ms，而有1次是1s，那么平均数据就是100ms，很明显，这完全不能反应性能测试的情况，也许那1s的请求就是一个不正常的值，是个噪点。所以，我们会在一些评委打分中看到要去掉一个最高分一个最低分，然后再算平均值。
另外，中位数（Mean）可能会比平均数要稍微靠谱一些，所谓中位数的意就是把将一组数据按大小顺序排列，处在最中间位置的一个数叫做这组数据的中位数 ，这意味着至少有50%的数据低于或高于这个中位数。
当然，最为正确的统计做法是用百分比分布统计。也就是英文中的TP – Top Percentile ，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.9%的请求必须小于1ms，所有的平均时间必须小于1ms。两个条件的限制。（当年在天猫做聚石塔的时候，我要求阿里云的OpenAPI的性能测试给我一个TP99，结果我给阿里云的QA和开发解释一两周他们才明白是什么意思，最后也没有给出来，主要原因是，系统架构太复杂，不知道怎么测试，另外，响应时间极其不稳定，TP99基本上来说是相当难看）
为什么响应时间（latency）要和吞吐量（Thoughput）挂钩
系统的性能如果只看吞吐量，不看响应时间是没有意义的。我的系统可以顶10万请求，但是响应时间已经到了5秒钟，这样的系统已经不可用了，这样的吞吐量也是没有意义的。
我们知道，当并发量（吞吐量）上涨的时候，系统会变得越来越不稳定，响应时间的波动也会越来越大，响应时间也会变得越来越慢，而吞吐率也越来越上不去（如下图所示），包括CPU的使用率情况也会如此。所以，当系统变得不稳定的时候，吞吐量已经没有意义了。吞吐量有意义的时候仅当系统稳定的时候。
所以， 吞吐量的值必需有响应时间来卡。比如：TP99小于100ms的时候，系统可以承载的最大并发数是1000qps 。这意味着，我们要不断的在不同的并发数上测试，以找到软件的最稳定时的最大吞吐量。
为什么响应时间吞吐量和成功率要挂钩
我们这应该不难理解了，如果请求不成功的话，都还做毛的性能测试。比如，我说我的系统并发可以达到10万，但是失败率是
40%，那么，这10万的并发完全就是一个笑话了。
性能测试的失败率的容忍应该是非常低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊。
》》》推荐阅读《《《
1、
2、
3、
4、
6、
7、
8、
9、
10、
11、
12、
13、
14、
15、
16、
17、
18、
19、
20、
22、
23、
24、
25、
26、
27、
28、