压力测试指标解读：TPS/QPS、响应时间、错误率、资源利用率、并发用户数
做压力测试这么多年，我见过太多团队一上来就猛怼并发，结果数据跑出来一脸懵——这指标到底啥意思？哪个才是关键？说实话，指标解读才是压测的核心能力。你跑不出数据是工具问题，你看不懂数据那就是能力问题了。
今天咱们就把这五个核心指标掰开揉碎，一个一个讲清楚。我保证，看完你就能自己分析压测报告了。
1. TPS 与 QPS：系统的“吞吐能力”
先说说这两个最容易混淆的概念。
TPS（Transactions Per Second），每秒事务数。一个事务通常包含一组完整的操作。比如你下单，从点击“购买”到收到“成功”响应，这算一个事务。
QPS（Queries Per Second），每秒查询数。它更偏向于读请求，比如你刷个页面，发起了10次接口调用，那就是10个QPS。
我个人习惯这样区分：
- 写操作、混合操作，看TPS
- 读操作、查询接口，看QPS
核心观点：TPS/QPS 是系统吞吐能力的直接体现。数值越高，说明系统处理能力越强。
我在项目中遇到过一个问题：某电商大促前压测，TPS 一直上不去，卡在 2000 左右。排查了半天，发现是数据库连接池配小了。你想想看，连接池就 50 个，你并发再高也没用，都在排队等连接。
这里有个经验值：
- 一般业务系统：TPS 1000~5000 算正常
- 高并发场景（如秒杀）：TPS 需要上万甚至十万级
- 如果 TPS 低于预期，先看瓶颈在哪——是 CPU 满了？还是数据库慢了？
2. 响应时间：用户的“等待感”
响应时间，说白了就是用户从发出请求到收到响应，一共等了多久。
这个指标我特别看重。为什么？因为它是用户体验的直接映射。你系统再牛，用户等 5 秒才打开页面，那用户早跑了。
响应时间通常看三个值：
| 指标 | 含义 | 建议值 |
|---|---|---|
| 平均响应时间 | 所有请求的平均耗时 | < 500ms |
| P90 响应时间 | 90% 的请求在这个时间内完成 | < 1s |
| P99 响应时间 | 99% 的请求在这个时间内完成 | < 2s |
嗯，这里要注意：平均响应时间容易被“平均”掉。比如 100 个请求，99 个是 100ms，1 个是 10s，平均下来才 200ms，看起来挺好。但那个 10s 的用户已经骂娘了。
所以我建议重点看 P99。它能反映最差情况下的体验。
我的小技巧：压测时如果发现 P99 突然飙升，大概率是某个资源（CPU、内存、IO）达到了瓶颈。这时候别急着调代码，先看看监控曲线。
3. 错误率：系统的“健康度”
错误率，就是所有请求中，返回错误的比例。
这个指标其实很简单：
- 错误率 = 错误请求数 / 总请求数 × 100%
但简单归简单，它背后的信息量很大。
我曾经遇到一个案例：压测到 500 并发时，错误率突然从 0% 飙到 15%。一看日志，全是“Connection timeout”。这说明什么？说明后端服务扛不住了，连接池被耗尽，新请求只能排队等，等超时了就报错。
错误率一般要求：
- 正常压测：错误率 < 1%
- 极限压测：可以容忍 1%~5%
- 超过 5%：系统已经处于不稳定状态，需要立即排查
注意：错误率不是越低越好。有时候为了追求 0% 错误率，你把并发压得很低，那压测就失去了意义。我们要的是在合理并发下，错误率可控。
4. 资源利用率：CPU、内存、IO
这个指标是定位瓶颈的关键。你 TPS 上不去，错误率飙升，到底是谁的锅？看资源利用率就知道了。
CPU 利用率：
- 理想范围：70%~80%
- 超过 90%：CPU 已经成为瓶颈
- 低于 30%：资源浪费，可以加大并发
我记得有一次压测，CPU 一直跑在 95% 以上，但 TPS 就是上不去。一看代码，发现有个循环里做了大量的字符串拼接，用了 String 而不是 StringBuilder。改完之后，CPU 降到 60%，TPS 翻了一倍。
内存利用率：
- 关注点不是用了多少，而是 GC 频率和 Full GC 次数
- 如果内存使用率持续走高，且 Full GC 频繁，说明有内存泄漏
IO 利用率：
- 磁盘 IO：看 IOPS 和吞吐量
- 网络 IO：看带宽和连接数
- IO 高但 CPU 低，说明系统在等 IO，典型的 IO 密集型瓶颈
一句话总结：CPU 高是计算瓶颈，IO 高是存储/网络瓶颈，内存高是资源泄漏或配置不当。
5. 并发用户数：系统的“承载能力”
并发用户数，就是同一时刻有多少用户在访问系统。
这个指标我经常被问到：“我的系统能支持多少并发？”
说实话，这个问题本身就有问题。并发用户数不是一个固定值，它和响应时间、TPS 是强相关的。你想想看：
并发用户数 = TPS × 平均响应时间
举个例子：
- TPS = 1000，平均响应时间 = 200ms
- 那么并发用户数 = 1000 × 0.2 = 200
也就是说，200 个用户同时在线，系统就能达到 1000 TPS。
如果响应时间变长到 500ms，同样的 TPS 就需要 500 个并发用户。所以并发用户数不是一个独立指标，它和响应时间、TPS 是“铁三角”关系。
我个人习惯这样评估：
- 先定目标 TPS
- 再测平均响应时间
- 最后算出需要的并发用户数
如果并发用户数远超预期，说明响应时间太长了，需要优化。
知识体系总览
下面这张图，是我自己总结的压测指标关系图。你看一眼就能明白它们之间是怎么联动的。
这张图你看懂了吗？五个指标不是孤立的，它们是一个整体。TPS 上不去，可能是响应时间太长；响应时间长，可能是资源利用率过高；资源利用率高，又会导致错误率上升。一环扣一环。
实战建议：拿到压测报告，先看错误率——如果错误率正常，再看 TPS 和响应时间——如果这两个有问题，最后看资源利用率。这个顺序能帮你快速定位问题。
好了，这五个指标就讲完了。说实话，指标本身不难，难的是怎么把它们串起来看。你多跑几次压测，多分析几份报告，慢慢就有感觉了。