关于性能测试

关于性能测试

在开始讨论之前，先明确几个问题： 关于性能测试，存在三个核心问题需予关注：

1）测试普遍依赖于平均值，然而，必须指出，平均值作为单一指标具有其局限性，往往难以准确反映实际性能状况，因此其可靠性大大降低。

2）在测试过程中，响应时间的评估不能与吞吐量（如TPS/QPS）建立有效关联，仅仅局限于低速率场景下的测试，这种做法显然是不妥的，因为它忽视了系统在高负载下的性能表现。

3）此外，响应时间与吞吐量指标不能能与成功率紧密结合进行分析。这钟缺失导致对系统整体性能及稳定性的评估不够全面，因为成功率是衡量系统能否稳定提供服务的关键因素之一。

为什么平均值不靠谱

关于平均值为何不靠谱，相信大家在阅读新闻时经常会遇到类似平均工资、平均房价、平均支出等词汇。其实这些数据本质上只是“数学游戏”，对于理工科的朋友来说，或许天生就对此有所免疫。

同样，在软件性能测试中，平均值的作用也十分有限。可以参考这篇详细的文章《Why Averages Suck and Percentiles are Great》，这里我简要说明一下。

性能测试的数据往往波动较大。比如，在10次测试中，有9次响应时间为1ms，但有1次为1s，那么平均值将是100ms。然而，这个值完全无法反映真实情况。或许1s的请求是异常值（噪点），应予以剔除。这也是为什么在一些评委打分中会去掉最高分和最低分再计算平均值。

相比之下，中位数（Median）比平均值稍显可靠。中位数是指将数据按大小排列后处于中间位置的值，这表明至少有50%的数据低于或高于这个值。

但最理想的统计方法是采用百分比分布（Top Percentile, TP）。例如，TP50表示50%的请求小于某个值，TP90表示90%的请求小于某个值。例如，对数据[10ms, 1s, 200ms, 100ms]进行排序后为[10ms, 100ms, 200ms, 1s]，TP50即为第二个值（100ms），TP90为第四个值（1s）。

我曾在路透公司进行金融系统性能测试时，要求是99.9%的请求必须小于1ms，且所有平均时间小于1ms。这说明平均值和百分比分布都需要合理结合使用。

为什么响应时间（latency）要和吞吐量（throughput）挂钩

仅关注系统的吞吐量而忽视响应时间是毫无意义的。例如，一个系统能处理10万请求，但响应时间达到了5秒，这样的性能是不可接受的。

随着并发量（吞吐量）的增加，系统会变得不稳定，响应时间波动加剧且逐渐变慢，最终吞吐量甚至无法提升（如下图所示）。包括CPU使用率在内的其他资源也会受到类似影响。因此，吞吐量仅在系统稳定时才具备参考价值。

吞吐量的测试必须以响应时间为约束条件。例如，TP99小于100ms时，系统的最大并发量为1000qps。这需要通过不同的并发量测试找到系统的最稳定吞吐量。

为什么响应时间、吞吐量和成功率要挂钩

性能测试的首要前提是请求成功率高。如果系统能支持10万并发请求但失败率高达40%，那这样的测试结果毫无意义。

关键系统的成功率要求通常是100%。对于性能测试中的失败率，容忍度必须极低。

如何严谨地做性能测试

性能测试需要综合考虑以下几个关键因素：吞吐量、响应时间、资源利用率（CPU/MEM/IO/Bandwidth等）、成功率和系统稳定性。以下是一些严谨的测试方法：

1. 定义响应时间和成功率标准。例如，TP99响应时间需在1ms以内，成功率必须达到100%。
2. 在响应时间限制下寻找最高吞吐量。测试数据需覆盖大小不一的多种情况，最好使用生产环境中的真实数据。
3. 进行Soak Test。在找到的最大吞吐量下，连续运行系统7天，监控CPU、内存、硬盘/网络IO等指标的稳定性。
4. 测试系统极限值。在成功率100%的前提下（不考虑响应时间），测量系统短时间内能承受的最大吞吐量。
5. 执行Burst Test。交替运行高负载与低负载，观察系统资源曲线和响应时间的波动情况。
6. 测试低吞吐量和小包传输。低负载可能引发响应时间异常或带宽不足的问题，这需要特别关注。

笔者实际经验发现，性能测试中会将最高吞吐量的69%作为软报警线，79%作为硬报警线，而极限值仅用于应对突发峰值。

性能测试工程需要严谨，因为性能测试工程本质上是一门严谨的学科。欢迎分享您对性能测试的经验和见解！