压测指标：QPS、TPS、响应时间、并发用户数、吞吐量、错误率、资源利用率

做压测这么多年，我见过太多人一上来就问「你们系统能扛多少并发？」。说实话，这个问题本身就不够严谨。你想想看，没有明确的指标定义，你怎么判断系统到底行不行？

今天我就把这七个核心指标掰开揉碎了讲清楚。每个指标我都踩过坑，有些坑还挺深的。

1. QPS 与 TPS：别再傻傻分不清

QPS（Queries Per Second），每秒查询数。说白了就是系统一秒能处理多少个请求。我习惯把它理解为「敲门次数」。

TPS（Transactions Per Second），每秒事务数。一个事务可能包含多个请求。比如你下单买东西，从点击购买到支付成功，这整个流程才算一个事务。

我在项目中遇到过这样的情况：某个电商系统，QPS 显示 5000，看起来挺猛。但一查 TPS，只有 200。为什么？因为每个下单事务要调 25 个接口。QPS 再高，业务没走完也是白搭。

2. 响应时间：用户等得起吗？

响应时间就是用户发出请求到收到响应的时间差。单位通常是毫秒。

我习惯把响应时间分成三档：

级别	时间范围	用户体验
优秀	0-200ms	感觉不到延迟
良好	200-500ms	轻微感知，可接受
糟糕	1s 以上	用户可能流失

这里有个坑：平均响应时间会骗人。比如 100 个请求，99 个 100ms，1 个 10s，平均下来才 200ms 左右。看起来不错？但那个倒霉的用户已经骂娘了。

3. 并发用户数：别被数字忽悠了

并发用户数，指的是同一时刻系统正在处理的用户数量。注意是「正在处理」，不是「在线人数」。

举个例子：一个直播间有 10 万人在线，但真正在发弹幕的只有 1000 人。并发用户数是 1000，不是 10 万。

我见过有人把在线人数当并发数去压测，结果系统直接崩了。嗯，这其实是个很常见的误解。

4. 吞吐量：系统到底能扛多少？

吞吐量是单位时间内系统处理的请求总量。常见单位有：

• 请求数/秒
• 数据量 MB/s
• 事务数/秒

吞吐量和响应时间其实是跷跷板关系。你想想看，响应时间越短，单位时间内能处理的请求就越多，吞吐量自然就上去了。

我在做压测时，习惯先定一个可接受的响应时间上限，然后在这个前提下尽量压高吞吐量。比如「响应时间不超过 500ms 时，吞吐量要达到 3000 QPS」。

5. 错误率：零错误是骗人的

错误率就是失败请求占总请求的比例。理想情况是 0%，但现实中几乎不可能。

常见的错误类型：

• 超时错误
• 连接拒绝
• 业务逻辑错误
• 服务器 5xx 错误

我建议：核心业务的错误率必须为 0%，非核心业务可以容忍 0.1%-0.5%。

6. 资源利用率：服务器累不累？

资源利用率包括 CPU、内存、磁盘 I/O、网络带宽等。说白了就是看服务器被榨干了没有。

资源	健康范围	危险信号
CPU	70% 以下	持续 90% 以上
内存	80% 以下	接近 100% 或频繁 GC
磁盘 I/O	等待时间 < 10ms	等待时间 > 50ms
网络	带宽使用率 < 70%	丢包率 > 0.1%

我个人习惯在压测时同时监控这四个指标。如果 CPU 还没到 60% 但响应时间已经飙了，那大概率是代码有问题，不是硬件瓶颈。

7. 这些指标怎么配合使用？

七个指标不是孤立的。我一般这样用：

1. 先定目标：响应时间 TP99 < 500ms，错误率 < 0.1%
2. 逐步加压：从 100 并发开始，每次加 100，观察各指标变化
3. 找到拐点：当某个指标突然恶化时，那个点就是系统的极限
4. 分析瓶颈：看是 CPU 满了？内存不够？还是数据库扛不住了？
5. 优化后重测：改完代码再跑一遍，看指标有没有改善

举个例子。有一次我压测一个支付系统，并发到 500 时，响应时间突然从 200ms 飙到 2s。一看监控，CPU 才 40%，但数据库连接池用满了。嗯，问题不在应用层，在数据库连接配置上。

好了，这七个指标就讲到这里。下一章我会讲怎么搭建压测环境，包括工具选型、数据准备、监控配置这些实战内容。到时候我会分享一些我踩过的坑，保证有用。