性能测试概论（一）

继自动化之后，再讲讲性能测试。相对于自动化，性能涉及的领域会更加广泛，比如架构、中间件、代码、监控等等。正因如此，本系列充其量也只能探其一二，权当给大家做个参考。话不多说，开始正文。

01. 性能及性能测试

提到性能，很多人会想到压测，再想到 LoadRunner 或 JMeter，但它们只是性能测试领域里很小的一部分。那么什么是性能呢？从用户的角度看来，当我们在使用一个应用（Web 或 APP）的时候，如果它能够在较短的时间内，给到相应的操作反馈，我们就认为这个应用的性能是好的。所以简单的性能可以理解为：系统处理用户请求所需的时间。

再扩展一下，有两个差不多功能的应用 A 和 B。A 在运行时，需要占用 50% 的 CPU，以及 300M 的内存；B 在运行时，只需要占用 30% 的 CPU，以及 100M 的内存。即便它们的反馈时间一样，我们肯定也认为 B 的性能比 A 更好。所以完善一下性能的定义：系统处理用户请求所需的时间以及消耗的资源。

性能主要包含两类关键指标：时间和资源。单一系统的性能指标在不同条件下的表现也不同，比如打开一个含有十张图片的相册，和打开一个含有一万张图片的相册，性能表现上肯定会有差异。因此在谈论性能的时候，还要加上相关场景的设定。那么所谓的性能测试就是：评估系统在特定场景下性能指标的测试方法。

对性能的容忍度在不同场景下的要求也不一样。比如我们购买一件商品，通常希望能够尽快下单成功，如果提交购买的页面一直在 Loading，很有可能就会放弃下单；而当我们需要下载一份历年的购买记录，即便等待 1-2 分钟，一般也可以接受。所以性能好坏的评价标准，其实是一个体验问题。

基于此，有很多性能优化手段并非以提升处理能力的方式来实现，而是在用户体验层面做出调整。比如较为常见的下载进度条、骨架屏、图片延时加载等等，先给到用户一个“我已经开始响应”的暗示，再逐步完成整个请求，让用户在主观感受上觉得会“更快”。关于这点，我们在后续的性能优化技术部分再慢慢展开。

02. 常见性能概念

我们来设置如下场景：景点有 3 个售票窗口，每个窗口 1 分钟可以接待 4 位游客。淡季时，景点每分钟迎来 3 位游客，那么窗口的接待效率完全可以满足要求，所有游客都能快速取票；旺季时，景点每分钟迎来 16 位游客，而窗口的最大接待量为 12人/分钟，这时必然会产生排队现象，部分游客就会因为排队时间过久而放弃。

在上面这个场景里，单个游客从开始排队到拿到门票的这个过程，我们称之为一个“事务”（Transaction），窗口每分钟可以完成 4 个事务，即代表系统处理每个事务的处理时间是 60/4 = 15s。游客在过程中花费的时间，我们称之为响应时间（RT，Response Time），在淡季时，游客因为完全不需要排队等待，响应时间等于事务处理时间，即 RT = 15s。

景点在单位时间内迎来的游客数，我们称之为请求量（RPS/RPM，Requests per Second/Minute）。比如淡季时每分钟景点到达的游客数是 3 ，即 RPS = 0.05/s 或 RPM = 3/min。景点在单位时间内可以完成的事务数，我们称之为吞吐量（TPS/TPM，Transactions per Second/Minute）。如上例，每分钟景点完成 3 个游客的接待，即 TPS = 0.05/s 或 TPM = 3/min。RPS/RPM 代表的是请求侧的输入频率，而 TPS/TPM 代表的是服务侧的处理效率。

还有一个类似的概念是点击量（HPS/HPM，Hits per Second/Minute）。比如景点需要靠班车才能抵达，每分钟一班，每班可载送 6 名游客，我们理解为一次运载（点击）带来 6 次游客访问（请求），所以此时 RPS = HPS * 6。HPS 与 RPS 的关系，更像是一种总与分的关系，但在实际应用中不太常见，有所了解即可。

对应的，TPS 也有一个相伴的概念是查询量（QPS/QPM，Queries per Second/Minute）。比如每位游客在购票时包括三个步骤：询问票价、提交证件、申请发票，我们理解为一次购票行为（事务）对窗口（系统）的查询量为 3，所以此时 QPS = TPS * 3。QPS 的定义有时比较模糊，也经常 与 TPS 混淆，不用过于在意。

03. 进一步理解

现在我们把每分钟的游客数提升到 12（假定游客以相同间隔时间匀速到来），刚好达到景点的最大接待量，窗口完全没有空闲时间，持续不停地在运转，游客仍然不需要排队，所以 RT 依然是 15s，而景点的 TPM 则达到了最高，为 12/min，我们称之为最大吞吐量。

当然，这种匀速的情况比较理想化，现实中往往不会如此。继续前面的案例，景点每分钟仍然有 12 位游客到达，但并不是匀速的。比如某个特定分钟内，第 1s 就来了 12 位游客，后面 59s 一个也没有来。这 1s 的时间，我们把它叫做访问高峰期，其余的 59s 叫做访问空闲期。

这时每个窗口会有 4 位游客同时到达，排在第一位的游客只要 15s 就可以完成取票，而第二位游客需要排队等待 15s，加上取票的 15s，总共要用 30s 才能完成取票，即 RT = 30s。以此类推，第三位游客 RT = 45s，第四位游客 RT = 60s，他们的平均响应时间就是 (15s + 30s + 45s + 60s)/4 = 37.5s。

而游客的耐心总是有限的，假设他们能够忍受的最长等待时间是 50s，那么在上面的情形下，第四位游客会因为等待时间过长而离开，我们把这个最长等待时间称之为连接超时时间。最终有 75% 的游客成功取票，那么我们就说成功率 = 75%，反之，失败率 = 25%。

到了旺季，每分钟的游客数上升到了 16（RPM = 16/min），超过了景点的最大接待量，那么会有部分游客的等待时间 > 连接超时时间，相比淡季时成功率下降，失败率上升。而窗口由于源源不绝的游客到来，TPM 一直维持在 12/min，因此可知，当 RPM > TPM（或 RPS > TPS）时，系统处于超载状态，失败率就会提高。

(未完待续…)