性能测试应该怎么作？

偶然间看到了阿里中间件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。两个条件的限制。

为何响应时间（latency）要和吞吐量（Thoughput）挂钩

系统的性能若是只看吞吐量，不看响应时间是没有意义的。个人系统能够顶10万请求，可是响应时间已经到了5秒钟，这样的系统已经不可用了，这样的吞吐量也是没有意义的。

咱们知道，当并发量（吞吐量）上涨的时候，系统会变得愈来愈不稳定，响应时间的波动也会愈来愈大，响应时间也会变得愈来愈慢，而吞吐率也愈来愈上不去（以下图所示），包括CPU的使用率状况也会如此。因此，当系统变得不稳定的时候，吞吐量已经没有意义了。吞吐量有意义的时候仅当系统稳定的时候。

因此，吞吐量的值必需有响应时间来卡。好比：TP99小于100ms的时候，系统能够承载的最大并发数是1000qps。这意味着，咱们要不断的在不一样的并发数上测试，以找到软件的最稳定时的最大吞吐量。

 

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

咱们这应该不难理解了，若是请求不成功的话，都还作毛的性能测试。好比，我说个人系统并发能够达到10万，可是失败率是

40%，那么，这10万的并发彻底就是一个笑话了。

性能测试的失败率的容忍应该是很是低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊。

 

如何严谨地作性能测试

通常来讲，性能测试要统一考虑这么几个因素：Thoughput吞吐量，Latency响应时间，资源利用（CPU/MEM/IO/Bandwidth…），成功率，系统稳定性。

下面的这些性能测试的方式基本上来源自个人老老东家汤森路透，一家作real-time的金融数据系统的公司。

一，你得定义一个系统的响应时间latency，建议是TP99，以及成功率。好比路透的定义：99.9%的响应时间必需在1ms以内，平均响应时间在1ms之内，100%的请求成功。

二，在这个响应时间的限制下，找到最高的吞吐量。测试用的数据，须要有大中小各类尺寸的数据，并能够混合。最好使用生产线上的测试数据。

三，在这个吞吐量作Soak Test，好比：使用第二步测试获得的吞吐量连续7天的不间断的压测系统。而后收集CPU，内存，硬盘/网络IO，等指标，查看系统是否稳定，好比，CPU是平稳的，内存使用也是平稳的。那么，这个值就是系统的性能

四，找到系统的极限值。好比：在成功率100%的状况下（不考虑响应时间的长短），系统能坚持10分钟的吞吐量。

五，作Burst Test。用第二步获得的吞吐量执行5分钟，而后在第四步获得的极限值执行1分钟，再回到第二步的吞吐量执行5钟，再到第四步的权限值执行1分钟，如此往复个一段时间，好比2天。收集系统数据：CPU、内存、硬盘/网络IO等，观察他们的曲线，以及相应的响应时间，确保系统是稳定的。

6、低吞吐量和网络小包的测试。有时候，在低吞吐量的时候，可能会致使latency上升，好比TCP_NODELAY的参数没有开启会致使latency上升（详见TCP的那些事），而网络小包会致使带宽用不满也会致使性能上不去，因此，性能测试还须要根据实际状况有选择的测试一下这两咱场景。

（注：在路透，路透会用第二步获得的吞吐量乘以66.7%来作为系统的软报警线，80%作为系统的硬报警线，而极限值仅仅用来扛突发的peak）

是否是很繁锁？是的，只由于，这是工程，工程是一门科学，科学是严谨的。

总结：

1. 平均值不靠谱，要使用百分比统计

2. 响应时间（latency）、吞吐量（Thoughput）和成功率要挂钩，不能单看吞吐量

3. 性能测试是项严谨的工做，它是一项工程，必须从指标设计、基线测试、混合测试、耐力测试、极限测试、爆裂测试（Burst Test）等等

     

在web应用中，吞吐量这个概念是会细分为并发数（跟用户数正相关）和QPS的，在限制latency 都是 1ms 的状况下，并发100 时的QPS和200时的是不同的，这样咱们说系统的承载能力有多大的时候，就要描述两个变量：在并发为n的状况下QPS为m是否可用。这时候测试画出来的图应该是三维的（latency concurrency QPS），表现是一个面，再限制latency=1ms，该面在此限制之下的部分为可用临界，其在QPS-concurreny平面的投影，才是系统可用数据。 具体作法就是 测各个并发下响应延迟在1ms下的最大QPS，而后以横轴为并发数，纵轴为QPS，画图，曲线和坐标轴围城的区域就是可用区域（这个区域其实就是上面三维图像的投影） 但是不知为啥不多看到有人这样压测。