2、核心指标定义：响应时间、吞吐量、并发用户数、错误率、资源利用率（CPU/内存/IO）

做性能回归对比，说白了就是拿两轮测试数据放一起比。但比什么呢？你得先知道看哪些指标。我见过不少团队，一上来就盯着响应时间看，结果系统挂了都不知道为什么。今天我把五个核心指标掰开揉碎了讲清楚。

响应时间，就是从用户发出请求到收到完整响应所花的时间。单位通常是毫秒或秒。我个人习惯把它拆成三部分：

我在项目中遇到过一个问题：某接口平均响应时间只有 50ms，但用户总说卡。后来一查，原来是 99 分位响应时间到了 3 秒。你想想看，平均时间会掩盖掉那些慢请求。所以我的建议是：

重点关注 TP95、TP99 甚至 TP999 分位值，而不是只看平均值。

举个例子，一个电商下单接口，压测数据如下：

看到没？平均只涨了 12%，但 TP99 快翻倍了。这种回归，必须深挖。

吞吐量，单位时间内系统能处理的请求数量。常见单位有 TPS（每秒事务数）、QPS（每秒查询数）、RPS（每秒请求数）。

说白了，响应时间看的是快不快，吞吐量看的是多不多。这两个指标通常成反比——你让系统跑得更快，它往往能处理更多请求。但也不是绝对的，我踩过这个坑。

我曾经优化了一个接口的响应时间，从 200ms 降到了 50ms，结果吞吐量反而下降了。为什么？因为我加了缓存，但缓存击穿导致大量线程阻塞。嗯，这里要注意：优化单个请求，可能引发全局连锁反应。

回归对比时，我一般这样看吞吐量：

并发用户数，不是指系统总用户数，而是同一时刻正在发起请求的用户数。注意，是在线的，不是注册的。

我见过有人把注册用户数当并发数汇报，那完全是两码事。并发用户数直接影响系统的资源消耗。回归测试时，我习惯这样设计：

对比时，重点关注：在相同并发下，新版本的性能是否变差。如果新版本在 500 并发时就扛不住了，而基线能扛到 800，那就是明显的回归。

小技巧：并发用户数不是越高越好。找到系统的「拐点并发」——就是再增加用户，吞吐量不再增长的那个点。这个点最能反映系统容量。

错误率，就是失败请求占总请求的比例。通常用百分比表示。HTTP 层面常见的有 4xx、5xx，业务层面还有自定义错误码。

回归对比时，错误率的变化往往比响应时间更致命。我遇到过的情况：

我的原则：错误率超过 1% 就必须停下来分析。别想着「先跑完再说」，那是在浪费时间。

资源利用率包括 CPU、内存、磁盘 I/O、网络 I/O。这些指标告诉你，系统到底把硬件用到了什么程度。

我一般这样看：

回归对比时，我最关注的是：同样的负载下，资源消耗是否变高了。如果响应时间没变，但 CPU 从 50% 涨到了 75%，说明代码效率下降了。

我曾经遇到一个案例：新版本上线后，CPU 直接飙到 95%，但响应时间反而快了。后来发现是加了死循环重试机制——用 CPU 换响应时间，这绝对是个馊主意。

这五个指标不是孤立的。我画了张图，帮你理清它们之间的关系：

从图上你能看到：并发用户数上去后，资源利用率跟着涨，响应时间变长，吞吐量到拐点后开始下降，错误率在资源耗尽时飙升。这就是连锁反应。

回归对比时，我建议你把这五个指标放在一张表里看。别单独看某一个，那会漏掉关键信息。

我的习惯：每次回归测试，先看错误率有没有变化，再看资源利用率是否异常，最后才看响应时间和吞吐量。顺序很重要，能帮你快速定位问题。

好了，这五个指标的定义和关系就讲到这里。记住，指标是工具，不是目的。目的是通过它们发现性能回归，找到根因，然后修复它。