2. 核心指标定义：QPS/TPS、响应时间(TP99/TP999)、错误率、资源利用率(CPU/内存/IO)
做压力测试，说白了就是给系统「上强度」。但怎么判断系统扛不扛得住？不能光凭感觉。你得盯住几个关键指标。我这些年踩过的坑，十有八九都是因为指标没看全，或者看错了。
这一章，我把压测最核心的四个指标掰开揉碎了讲。你记住，这四个指标就像汽车的仪表盘——少一个，你都可能翻车。
2.1 QPS 与 TPS：别傻傻分不清
很多人把 QPS 和 TPS 混着用。我刚开始也犯过这错。后来被一个老架构师怼了一句：「你连测的是请求还是事务都分不清，压个寂寞？」
嗯，从那以后我分得清清楚楚。
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读接口、搜索、列表页 |
| TPS | Transactions Per Second | 每秒事务数 | 下单、支付、风控决策 |
QPS 侧重「查询」。比如你查一个用户的订单列表，一次请求就算一个 QPS。它通常是无状态的，响应快，对系统压力相对小。
TPS 侧重「事务」。一个事务可能包含多个请求。比如风控系统里，一次「交易审核」可能涉及：查黑名单、查设备指纹、跑规则引擎、写日志。这一整套下来，才算一个 TPS。
我的习惯：压测风控系统，我只看 TPS。因为风控的每一次决策都是一个完整事务。只看 QPS 会严重低估系统压力。
举个例子。你压测一个风控决策接口，压到 2000 QPS 感觉还行。但仔细一看，每个 QPS 背后其实包含了 5 次内部调用。那实际 TPS 只有 400。系统真正的吞吐能力，是 400 TPS，不是 2000 QPS。
避坑指南：我曾经在压测报告里只写了 QPS，被老板表扬「性能不错」。结果上线第一天，真实流量一来，系统直接打满。后来复盘才发现，我压测时用的是简单查询接口，而线上全是复杂事务。从此以后，我压测报告里必须同时标注 QPS 和 TPS，并说明测试场景。
2.2 响应时间：TP99 和 TP999 才是真相
平均响应时间？那玩意儿骗人的。你想想看，100 个请求里 99 个 10ms，1 个 10s，平均一下才 109ms。看起来挺美，但那个倒霉的用户已经等崩溃了。
所以，我只看百分位响应时间。
- TP99：99% 的请求在多少毫秒内完成。剩下 1% 是长尾。
- TP999：99.9% 的请求在多少毫秒内完成。剩下 0.1% 是极端长尾。
为什么这两个指标重要？因为风控系统是「高敏感」系统。一个决策慢了，用户可能直接流失，或者被风控放过了一笔欺诈交易。
我的经验：风控系统的 TP99 建议控制在 200ms 以内，TP999 控制在 500ms 以内。超过这个阈值，说明系统已经接近瓶颈，需要扩容或优化。
怎么测？压测工具一般都会自动计算。比如用 JMeter，在聚合报告里就能看到 TP90、TP99、TP999。我习惯把 TP999 作为「红线指标」。一旦 TP999 超过阈值，我就认为系统不可用，哪怕平均响应时间还很低。
为什么会这样？因为 TP999 反映的是系统在最差情况下的表现。它暴露了资源竞争、锁冲突、GC 停顿等问题。这些问题平时不显眼，但流量高峰一来，就会放大成雪崩。
2.3 错误率：零容忍
错误率，就是压测过程中失败的请求占比。包括超时、返回 5xx、业务异常码等。
我对错误率的态度很简单：压测过程中，错误率必须为 0。
有人会说：「哎呀，偶尔几个超时很正常嘛，不影响整体。」
我不这么认为。你想想看，压测是模拟真实流量。如果压测时都有错误，线上只会更严重。而且，错误率是系统健康度的「晴雨表」。一旦出现非零错误率，说明系统已经进入不稳定状态。
| 错误类型 | 常见原因 | 我的处理方式 |
|---|---|---|
| 超时 | 线程池打满、数据库连接池耗尽 | 先看 TP999，如果 TP999 正常，可能是超时时间设置太短 |
| 5xx | 服务崩溃、内存溢出、依赖服务不可用 | 立即停止压测，排查日志 |
| 业务异常 | 风控规则返回错误、参数校验失败 | 检查压测数据是否合法，或者业务逻辑有 bug |
避坑指南：我曾经压测一个风控规则引擎，发现错误率 0.5%。排查了两天，最后发现是压测数据里混入了一条「测试用户」的黑名单记录，导致规则引擎抛了空指针。嗯，从那以后，我压测前都会先做数据清洗。
2.4 资源利用率：CPU、内存、IO
光看 QPS 和响应时间还不够。你得知道系统「累不累」。资源利用率就是系统的「疲劳度」。
CPU
CPU 利用率是核心指标。我一般看两个值：
- 用户态 CPU：业务代码在跑。如果这个高，说明业务逻辑复杂，需要优化代码。
- 系统态 CPU：内核在干活。如果这个高，说明系统调用频繁，比如大量 IO 操作。
我的经验是：CPU 利用率在 70% 以下算健康。超过 80%，系统就开始排队了。超过 90%，响应时间会急剧恶化。
内存
内存主要看两点：
- 堆内存使用率：Java 应用重点关注。如果堆内存持续增长，说明有内存泄漏。
- GC 频率和停顿时间：Full GC 一次超过 1 秒，系统基本就卡死了。
我记得有一次压测，QPS 上不去，CPU 也不高。排查了半天，发现是 GC 太频繁，大部分时间都在「Stop The World」。优化了堆内存配置后，TPS 直接翻了一倍。
IO
IO 包括磁盘 IO 和网络 IO。风控系统里，IO 瓶颈通常出现在：
- 数据库：慢查询、连接池打满
- 缓存：Redis 响应变慢
- 日志：写日志太频繁，磁盘 IO 打满
怎么判断 IO 是不是瓶颈？看 iowait。如果 iowait 超过 10%，说明磁盘在拖后腿。
我的习惯：压测时，我会同时开四个监控窗口：一个看 CPU 和内存，一个看 GC 日志，一个看数据库慢查询，一个看网络流量。哪个先报警，就先优化哪个。
2.5 核心指标关系图
下面这张图，是我自己总结的。它展示了四个核心指标之间的关联关系。你压测时，可以照着这张图来排查问题。
这张图想表达什么？说白了就是：没有孤立的指标。
- QPS 上去了，响应时间就会变长。
- 响应时间变长，超时增多，错误率就上来了。
- 错误率高了，系统忙着处理异常，资源利用率飙升。
- 资源利用率高了，反过来又限制了 QPS。
你压测时，如果发现某个指标异常，别只盯着它看。顺着这张图去排查上下游，往往能找到根因。
一个小技巧：我习惯在压测脚本里同时采集这四个指标，然后画在一张趋势图上。哪个指标先「翘头」，哪个就是瓶颈。比如，如果 CPU 先到 90%，那就是计算密集型瓶颈；如果 TP999 先翘头，那就是资源竞争或锁冲突。
好了，核心指标就讲这么多。记住这四个指标，你的压测报告就有了灵魂。下一章，我们会聊怎么搭建压测环境——嗯，这部分我踩过的坑更多，到时候慢慢说。
公众号:蓝海资料掘金营，微信deep3321