压测指标详解：TPS/QPS、响应时间、错误率、资源利用率
做压测这么多年，我见过太多团队上来就盯着一个数字看。要么只看 QPS，要么只盯着响应时间。结果呢？线上该挂还是挂。
其实压测指标就像人的体检报告。只看体温不行，还得看血压、心率、血氧。今天咱们就把这四大类指标掰开揉碎了讲清楚。
核心观点：压测不是跑个数字就完事，而是通过多维度指标交叉验证，找到系统的真实瓶颈。
一、TPS 与 QPS：你到底能扛多少
先说说这两个最容易搞混的概念。TPS 是每秒事务数，QPS 是每秒查询数。我习惯这么区分：一个完整的业务操作算 TPS，一次简单的查询算 QPS。
举个例子。你点了个“提交订单”，后端可能调了 5 个接口。这时候 TPS 是 1，QPS 可能是 5。明白了吧？
我的习惯：压测时优先关注 TPS。因为它更贴近真实用户体验。QPS 更多用来做接口级容量规划。
怎么算 TPS？看这个公式：
TPS = 总事务数 / 压测持续时间（秒）
举例：
压测 60 秒，完成 12000 个订单提交
TPS = 12000 / 60 = 200我在项目中遇到过一个问题：TPS 跑到 500 时，数据库连接池先爆了。你想想看，光看 TPS 数字漂亮没用，得看背后每个环节能不能跟上。
二、响应时间：别被平均值骗了
响应时间这块，我踩过最大的坑就是看平均值。平均响应时间 50ms，听起来很美对吧？但实际上一半的请求都超过 200ms。
所以业界普遍看百分位。常用的有三个：
| 指标 | 含义 | 典型阈值 |
|---|---|---|
| P50（中位数） | 50% 的请求在此时间内完成 | < 200ms |
| P95 | 95% 的请求在此时间内完成 | < 500ms |
| P99 | 99% 的请求在此时间内完成 | < 1000ms |
注意：P99 是排查长尾问题的关键。我曾经发现一个服务 P50 只有 30ms，但 P99 飙到了 3 秒。查了半天，原来是某个缓存 key 没命中，回源查数据库了。
为什么会这样？说白了，P99 暴露的是系统的“短板”。那 1% 的慢请求，往往就是线上故障的导火索。
三、错误率：零容忍还是可接受
错误率这个指标，不同业务容忍度完全不同。支付场景 0.01% 的错误都受不了，但一个资讯推荐服务，1% 的错误可能还能接受。
我一般这么分类：
- 硬错误：HTTP 5xx、超时、连接拒绝。这类必须零容忍。
- 软错误：业务返回码异常、数据校验失败。这类可以设定阈值。
压测时怎么算错误率？
错误率 = 错误请求数 / 总请求数 × 100%
举例：
总请求 10000，错误 23 个
错误率 = 23 / 10000 × 100% = 0.23%避坑指南：我曾经遇到一个情况，错误率只有 0.1%，但全是下单接口报错。业务影响巨大。所以不光看整体错误率，还要按接口拆分看。
四、资源利用率：CPU、内存、IO
资源利用率是压测的“照妖镜”。它能告诉你系统到底卡在哪。
4.1 CPU 利用率
CPU 跑到 80% 以上就要警惕了。我习惯分两个维度看：
- 用户态（user）：业务代码在跑。占比高说明计算密集。
- 系统态（sys）：内核在干活。占比高说明系统调用频繁。
4.2 内存利用率
内存泄漏是压测中最头疼的问题之一。我一般关注三个点：
- 堆内存使用趋势：是否持续增长
- GC 频率和停顿时间
- Swap 使用情况（有 swap 基本就废了）
4.3 IO 利用率
IO 分磁盘 IO 和网络 IO。磁盘 IO 高通常意味着日志写太多或者数据库刷盘频繁。网络 IO 高则可能是带宽瓶颈。
实战经验：有一次压测 TPS 上不去，CPU 才 30%，内存也够。查了半天发现磁盘 IO 跑满了。原来日志框架配置了同步刷盘，改成异步后 TPS 直接翻倍。
五、指标之间的关联分析
单个指标看完了，咱们说说怎么串起来看。这才是压测的精髓。
我总结了几种常见模式：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| TPS 低 + CPU 高 | 业务逻辑复杂，计算密集 | 优化算法，加缓存 |
| TPS 低 + CPU 低 + IO 高 | IO 瓶颈，等待磁盘或网络 | 检查数据库、日志、网络带宽 |
| TPS 高 + P99 飙升 | 系统在极限边缘运行 | 扩容或限流 |
| 错误率上升 + 内存持续增长 | 内存泄漏导致 OOM | dump 堆内存分析 |
切记：不要只看一个指标就下结论。我见过有人看到 CPU 高就加机器，结果发现是死循环。加再多机器也没用。
六、压测指标的最佳实践
最后分享几个我这些年总结出来的经验：
- 先定目标再压测。比如：TPS 必须到 1000，P99 不超过 500ms，错误率低于 0.1%。
- 阶梯加压。从 100 TPS 开始，每次加 100，观察指标变化。找到拐点。
- 持续压测。跑 30 分钟以上，看指标是否稳定。内存泄漏往往需要时间才能暴露。
- 记录基线。每次压测的结果都记录下来。方便对比优化效果。
嗯，指标这块就讲这么多。记住一句话：压测不是为了跑出好看的数字，而是为了找到系统的真实边界。下次你看到一份压测报告，别只看那个最大 TPS，把 P99、错误率、资源利用率都翻出来看看。你会发现很多有意思的东西。