云主机性能测试应该怎么做？

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

今天给大家介绍的就是阿 贝云主机，阿 贝云是提供免 费虚拟主机免 费云服务器的，希望大家不要错过了。

下面的这些性能测试的方式基本上来源自我的老老东家汤森路透。

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

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

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

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

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

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

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

是不是很繁锁？是的，只因为，这是工程，工程是一门科学，科学是严谨的。

总结：

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

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

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

在web应用中，吞吐量这个概念是会细分为并发数（跟用户数正相关）和QPS的，在限制latency 都是 1ms 的情况下，并发100 时的QPS和200时的是不一样的，这样我们说系统的承载能力有多大的时候，就要描述两个变量：在并发为n的情况下QPS为m是否可用。这时候测试画出来的图应该是三维的（latency concurrency QPS），表现是一个面，再限制latency=1ms，该面在此限制之下的部分为可用临界，其在QPS-concurreny平面的投影，才是系统可用数据。

具体做法就是 测各个并发下响应延迟在1ms下的最大QPS，然后以横轴为并发数，纵轴为QPS，画图，曲线和坐标轴围城的区域就是可用区域（这个区域其实就是上面三维图像的投影）

可是不知为啥很少看到有人这样压测。