性能测试：性能测试中的核心指标应该怎么看
性能测试里最常见的误区之一，就是只盯一两个数字下结论。
例如：
- QPS 很高，所以系统没问题
- 平均响应 200ms，所以体验很好
- CPU 70%，所以资源还够
这些判断都太粗。
它们不是完全错，而是只抓到了局部表象。
从真实项目里看，性能指标真正有价值的地方，不是告诉你“某个数是多少”，而是告诉你：
- 系统有没有在退化
- 退化是从哪里开始的
- 这个退化是局部抖动，还是系统性风险
而这些判断，通常都不是靠单个指标完成的。
一、先说结论：性能指标要看“组合”，不要看“单点”
性能测试里的核心指标通常可以分成四组：
- 吞吐类
- 延迟类
- 错误类
- 资源类
它们分别回答不同问题：
- 吞吐类：系统产出多少
- 延迟类：系统慢不慢、抖不抖
- 错误类：系统有没有开始失真或失败
- 资源类：系统靠什么在扛，哪里快到上限了
如果只看其中一类，通常都不够。
真正有意义的是把这几组指标放到同一时间轴上一起看。
二、吞吐指标看的是“系统产出能力”，但不能脱离错误率和延迟单独解释
吞吐最常见的指标就是：
- TPS
- QPS
看到吞吐高，直觉上很容易觉得系统能力强。
但这个判断要非常小心，因为吞吐高至少有三种完全不同的含义：
1. 真正健康的高吞吐
表现通常是：
- 吞吐增长平稳
- 响应时间没有明显恶化
- 错误率保持低位
这说明系统还在健康工作区。
2. 错误堆出来的高吞吐
例如：
- 接口快速失败
- 网关直接拒绝
- 下游超时前置返回
这种情况下，看起来吞吐也可能很高，但业务价值几乎为零。
3. 逼近极限前的“虚假繁荣”
有些系统在某个区间内，吞吐还能继续涨，但尾延迟和错误率已经开始抬头。
这往往意味着系统已经在透支稳定性换吞吐。
所以吞吐类指标的第一原则是：
至少要和响应时间、错误率一起看。
三、响应时间不要只看平均值，真正危险的是尾延迟
这是线上最典型也最容易被忽视的问题。
很多报告里都会先写平均响应时间，因为它看起来最直观。
但真实用户体验往往不是被平均值决定的，而是被尾部请求决定的。
比如一个接口：
- Avg 200ms
- P95 1.2s
- P99 4.8s
从平均值看，好像很好；
但从用户视角看，这已经是明显会被感知到卡顿的系统。
所以通常会重点看：
- Avg
- P90
- P95
- P99
其中：
- Avg 更像整体概览
- P95 / P99 更像真实风险指标
如果 P99 开始显著抬高，哪怕平均值还不错，我也会把它当成明确的退化信号。
四、错误率不是“最终失败数”，而是系统退化最敏感的外显信号
只有到错误率明显升高时才重视它。
但实际上，错误率在性能测试里应该被更细地拆开看。
因为“错误”本身不是一个单一概念。
常见至少要区分：
- 业务错误
- 接口超时
- 连接失败
- 网关返回错误
- 压测工具侧异常
这几类错误背后代表的含义完全不同。
例如：
- 业务错误高，可能是参数模型有问题
- 超时高，可能是下游阻塞或线程池排队
- 连接失败高，可能是网络、端口、句柄或网关资源先顶住了
- 工具侧异常高，可能是压测机自己先崩了
如果错误率只看一个总数，结论会非常粗糙。
五、资源类指标的价值，不是看“高不高”，而是看“有没有限制产出”
这也是最容易误判的一类指标。
这类指标组合一出现，最常见的判断是：
- CPU 高
- 内存高
- 磁盘 util 高
就直接说瓶颈在这里。
但真实分析里，更关键的问题是：
这个资源高利用率，到底有没有开始限制系统继续产出。
举几个例子：
1. CPU 高，不一定就是 CPU 瓶颈
如果 CPU 80% 但：
- 吞吐还在健康增长
- P99 没明显恶化
- 错误率也没抬头
那它更像“资源被充分利用”，而不是当前主瓶颈。
2. 内存高，也不一定是问题
比如缓存型服务，本来就应该吃更多内存。
关键不是内存高不高，而是：
- GC 是否恶化
- 回收是否异常
- 是否出现明显抖动
3. 磁盘和网络更要看延迟与等待
很多磁盘和网络问题，最危险的不是“打满了”，而是：
- await 明显升高
- RTT 明显升高
- 重传、排队、阻塞开始出现
这些信号往往比单纯使用率更早暴露风险。
六、真正有分析价值的，是指标之间的“联动关系”
做性能分析时，很少单看一张图。
更常见的是把几张图叠在脑子里一起解释。
例如一个典型的性能退化链路可能是：
- 吞吐继续上升
- P95 开始拉长
- CPU 接近上限
- 应用线程数明显增加
- 错误率开始从 0 升到 0.5%
这种联动关系通常比单个指标更能说明问题。
再比如另一种情况：
- 吞吐没怎么涨
- CPU 也不高
- 但 P99 很差
- 数据库连接池等待上升
这就提示你，问题可能根本不在应用 CPU，而在数据库侧排队。
所以更倾向把性能指标理解成一组“互相印证的证据”，而不是各看各的数字。
七、在项目里最常见的几个指标误读
误读 1：吞吐高就是系统强
没有结合错误率和延迟的吞吐结论，通常都不可靠。
误读 2：平均值好看就是体验好
很多严重问题都藏在 P95 / P99 里。
误读 3：某个资源高就是主瓶颈
资源高只能说明“忙”，不能直接说明“限制产出”。
误读 4：错误率低就代表系统稳定
有些系统在错误率还没明显抬头时，尾延迟和线程堆积已经先开始恶化。
如果只盯错误率，发现风险会太晚。
八、如果现场只允许我带一张指标记录表，更合适的设计方式如下
指标分析最怕“图很多，没人会串”。
如果现场只允许我保留一张核心记录表，通常会用下面这种结构。
| 阶段 | TPS | Avg | P95 | P99 | 错误率 | CPU | DB 连接等待 | 初步判断 |
|---|---|---|---|---|---|---|---|---|
| 100 并发 | 620 | 120ms | 210ms | 340ms | 0 | 42% | 低 | 健康区 |
| 200 并发 | 1180 | 160ms | 320ms | 520ms | 0 | 61% | 低 | 健康区 |
| 300 并发 | 1540 | 210ms | 480ms | 1.1s | 0.2% | 78% | 中 | 接近拐点 |
| 400 并发 | 1600 | 320ms | 920ms | 2.8s | 1.4% | 82% | 高 | 风险区 |
这张表不是为了替代监控图，而是为了逼自己在现场做解释：
- 吞吐是不是还在增长
- 尾延迟是不是已经先抬头
- 资源变化有没有和退化同步
- 这一阶段到底该叫健康区还是风险区
九、更常用的一套指标阅读顺序
如果面对一堆图表不知道先看什么，通常可以按下面顺序看。
- 先看吞吐有没有继续增长
- 再看 P95 和 P99 是不是开始分叉
- 再看错误率是不是同步抬头
- 最后对齐资源和依赖指标
原因很简单：
- 吞吐告诉你系统还有没有继续产出
- 分位数告诉你系统是不是开始抖
- 错误率告诉你系统是不是开始失真
- 资源告诉你失真可能从哪一层开始
这比上来先盯 CPU 或平均响应时间更不容易跑偏。
八、更常用的指标分析顺序
如果一次压测结果出来，通常会按下面顺序看：
1. 先看吞吐曲线
确认：
- 吞吐有没有正常爬升
- 是否存在明显平台期
- 是否出现突然掉头
2. 再看分位数延迟
确认：
- P95 / P99 从哪里开始恶化
- 是平滑变差，还是突然断崖
3. 再看错误率和错误类型
确认：
- 错误是业务错、超时错，还是连接错
- 错误从哪个阶段开始抬头
4. 最后对照资源指标
确认：
- 哪个资源在同一时间窗口最先达到上限
- 哪种资源变化和吞吐、延迟最同步
这样分析的好处是，不容易一上来就被某张资源图带偏。
结语
性能指标最怕的，就是被孤立地看。
真正有价值的分析，不是说“QPS 多少、平均响应多少、CPU 多少”，而是解释清楚：
- 产出有没有继续增长
- 用户体验在哪个阶段开始恶化
- 错误是怎么冒出来的
- 哪个资源最先开始限制系统继续产出
只有把吞吐、分位数、错误率和资源曲线放到同一时间轴上一起解释，性能结论才会真正站得住。