3. 核心指标定义：TPS、QPS、延迟、错误率、资源利用率

做压力测试，说白了就是给系统「上刑」。你得知道它什么时候扛不住，哪里先垮掉。但光靠感觉不行，得有数据说话。这一章，我把几个最核心的指标掰开揉碎讲清楚。

我个人习惯，每次压测前先跟团队对齐一个事：我们到底要测什么？ 是测接口能扛多少并发，还是测订单处理快不快？目标不同，关注的指标也不同。下面这几个，是绕不开的硬指标。

3.1 TPS 与 QPS：别傻傻分不清

很多新手容易搞混这两个概念。我简单解释一下：

• TPS（Transactions Per Second）：每秒完成的事务数。一个事务可能包含多个操作。比如一笔订单，从下单、扣库存、生成流水到返回结果，算一个完整事务。
• QPS（Queries Per Second）：每秒查询次数。通常指单一请求的响应能力，比如查询行情、查持仓。

在券商系统里，我一般更看重 TPS。为什么？因为一笔交易背后，数据库要写好几张表，缓存要更新，消息队列要发。QPS 高不代表事务处理能力强。你想想看，一个接口 QPS 能到 10 万，但一笔交易要调 5 个接口，那实际 TPS 也就 2 万。

我在项目中遇到过一件事：某次压测，开发说 QPS 到了 5 万，性能很好。结果我一查日志，发现他们测的是行情查询接口，根本不是交易链路。后来我让他们按真实场景压，TPS 直接掉到 3000。嗯，这就是典型的指标选错了。

3.2 延迟：P50、P95、P99 到底看哪个？

延迟就是响应时间。但只看平均值没意义。为什么？因为平均值会被少数慢请求拉高，也会被大量快请求拉低。你看到的平均延迟 50ms，可能 90% 的请求都在 10ms 内完成，剩下 10% 慢到 500ms。这能说明系统好吗？

所以，我们看百分位延迟：

• P50（中位数）：50% 的请求在这个时间内完成。代表大多数用户的体验。
• P95：95% 的请求在这个时间内完成。代表绝大多数场景。
• P99：99% 的请求在这个时间内完成。代表极端情况。

我个人习惯，P99 是红线。券商交易系统，P99 超过 500ms 基本就不可用了。你想想看，用户下单，等半秒才返回结果，他早就急得狂点重试了。重试又带来更多请求，系统雪上加霜。

这里给个参考标准（券商交易系统）：

指标	优秀	一般	危险
P50	< 10ms	10-50ms	> 50ms
P95	< 50ms	50-200ms	> 200ms
P99	< 100ms	100-500ms	> 500ms

3.3 错误率：别让 1% 毁了 99%

错误率很简单：失败请求数 / 总请求数。但这里有个坑——错误类型要区分。

• 业务错误：比如余额不足、股票停牌。这是正常业务逻辑，不算系统问题。
• 系统错误：比如超时、连接拒绝、500 错误。这才是我们要关注的。

我一般定两个阈值：

• 系统错误率 < 0.1%（千分之一）
• 压测过程中不允许出现连续错误

为什么这么严？因为券商交易系统，一笔错误可能意味着客户损失真金白银。我记得有一次压测，错误率只有 0.5%，看起来不高。但一查日志，全是订单提交超时。这意味着每 200 笔交易就有一笔没提交成功。客户能接受吗？绝对不行。

3.4 资源利用率：CPU、内存、IO、网络

光看应用层指标不够，底层资源也得盯。我习惯把资源利用率分成四类：

• CPU：看用户态、系统态、IO 等待。如果 CPU 跑满但 TPS 上不去，说明有锁竞争或死循环。
• 内存：关注堆内存使用、GC 频率。GC 太频繁会导致 STW（Stop The World），延迟飙升。
• 磁盘 IO：读写延迟、IOPS。数据库和日志写得多，磁盘容易成瓶颈。
• 网络：带宽、连接数、重传率。网络抖动会导致大量超时重试。

我个人经验，压测时资源利用率不要超过 70%。留 30% 的余量应对突发流量。你想想看，CPU 跑到 95%，再来一波行情波动，系统直接雪崩。

3.5 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当成一个检查清单：压测时，按这个顺序看指标，基本不会漏。

这张图你看懂了吗？从中心出发，四个维度展开。每个维度下都有具体指标和关键阈值。压测时，按这个框架去采集数据，基本不会漏掉重要信息。

---