压测指标详解：QPS/TPS、响应时间、并发用户数、资源利用率

各位同学，咱们今天聊点实在的。做压测这么多年，我见过太多人一上来就盯着一个数字看，比如“QPS 必须到 10 万”。结果呢？压是压上去了，系统也崩了。为什么？因为没搞懂这些指标到底在说什么。

说白了，压测指标就像人的体检报告。你不能只看体温，还得看血压、心率、血氧。今天我就带你把这几项“体检指标”掰开揉碎了讲清楚。

核心观点：压测不是跑个数字就完事，而是通过指标之间的关联，找到系统的真实瓶颈。

先讲最基础的。QPS 是每秒查询数，TPS 是每秒事务数。很多人搞混，我刚开始也犯过这个错。

QPS（Queries Per Second）：一般用在读场景。比如你刷朋友圈，每刷一次就是一次查询。

TPS（Transactions Per Second）：用在写场景，或者包含多个步骤的操作。比如下单，从点击“购买”到支付成功，这算一个完整事务。

举个例子：你打开一个电商首页，这算一次 QPS。但如果你下单、支付、确认收货，这算一次 TPS。嗯，这里要注意：TPS 通常包含多个 QPS。

我的经验：我在项目中遇到过，有人把 QPS 当 TPS 报给老板，结果上线后系统直接被打趴。为什么？因为一个 TPS 背后可能藏着 5-10 个 QPS。你压测时只看 QPS，实际流量一上来，数据库连接池瞬间就满了。

怎么算？很简单：

# 假设一个下单事务包含 3 次查询 + 1 次写入
# 如果系统 QPS 是 4000，那么实际 TPS 大约是：
TPS ≈ 4000 / 4 = 1000

所以，我建议你压测时，同时关注 QPS 和 TPS。别只看一个。

响应时间，说白了就是用户等多久。但“平均响应时间”是个大坑。你想想看，100 个请求里，99 个是 10ms，1 个是 10s，平均下来还是 100ms 左右。这能说明系统快吗？不能。

所以我们看百分位：

我个人习惯：P99 是红线，P90 是黄线，P50 是绿线。P99 超过 500ms，我就开始警觉了。

避坑指南：我曾经遇到一个项目，P50 只有 20ms，看起来很快。但 P99 高达 5s。查了半天，发现是某个缓存失效时，会触发全表扫描。那 1% 的用户恰好踩到了这个坑。所以，别只看 P50，P99 才是真正的“用户体验杀手”。

响应时间的分布，我一般这样看：

并发用户数，指的是同一时刻有多少用户在“干活”。注意，是“干活”，不是“挂着”。

很多人把“在线用户数”当“并发用户数”，这是大忌。你想想看，一个 App 有 100 万日活，但真正同时操作的，可能只有 1 万人。这 1 万人里，又只有 10% 在发请求。所以实际并发可能只有 1000。

怎么估算？我有个土办法：

# 经验公式
并发用户数 ≈ 在线用户数 × 操作频率 × 请求耗时

# 举例：1 万人在线，每人每分钟操作 2 次，每次请求耗时 200ms
并发用户数 ≈ 10000 × (2/60) × 0.2 ≈ 67 人

你看，实际并发只有 67，不是 1 万。所以压测时，别一上来就压 1 万并发，那是在浪费机器。

我的建议：从 50 并发开始，逐步往上加。每次加 50，观察响应时间和资源利用率的变化。当响应时间突然飙升时，那个点就是系统的“拐点”。

资源利用率，就是看系统“累不累”。CPU、内存、IO，这三兄弟要一起看。

这里有个经典场景：CPU 不高，但响应时间很长。为什么？大概率是 IO 在等。比如数据库查询慢，CPU 在等磁盘数据，所以 CPU 利用率上不去，但响应时间下不来。

避坑指南：我曾经遇到一个系统，CPU 只有 30%，但响应时间超过 2s。查了半天，发现是日志写得太频繁，磁盘 IO 被打满了。CPU 在等 IO 完成，所以看起来“不忙”，实际上系统已经快挂了。所以，资源利用率要组合看，别单看一个。

下面这张图，是我自己总结的压测指标关系图。你把它存下来，每次压测前看一眼，思路就清晰了。

这张图想表达什么？很简单：并发用户数是输入，QPS/TPS、响应时间、资源利用率是输出。你给系统施加压力，系统会给你三个反馈。这三个反馈要一起看，才能判断系统到底行不行。

好了，这一章就到这里。记住：压测不是跑数据，而是读数据。读懂了这些指标，你才算真正入门了。