性能指标详解：QPS/TPS、响应时间、并发用户数、吞吐量、资源利用率、P99/P95延迟
大家好，我是你们的老朋友。今天咱们来聊聊压测里最核心的东西——性能指标。
说实话，我见过太多人一上来就堆机器、跑脚本，结果数据出来了，一脸懵。为什么？因为根本不知道看什么指标。你想想看，就像开车不看仪表盘，光踩油门，迟早要翻车。
这一章，我把六个最关键的指标掰开揉碎了讲。每个指标我都会结合自己的实战经验，告诉你它到底有什么用，坑在哪里。
核心观点：性能指标不是孤立的数字，它们是一张网。一个指标异常，往往能牵出整个系统的病根。
1. QPS 与 TPS：系统的“吞吐能力”
先说 QPS（Queries Per Second）和 TPS（Transactions Per Second）。
QPS 指的是每秒查询数。说白了，就是系统一秒能处理多少个请求。TPS 呢，是每秒事务数。一个事务可能包含多个查询。
我个人习惯这样区分：
- QPS：适合读多写少的场景，比如搜索引擎、内容展示
- TPS：适合写操作多的场景，比如下单、支付、转账
举个例子。我在项目中遇到过一个大促场景，系统 QPS 飙到 5000，但 TPS 只有 200。为什么？因为大部分请求是浏览商品，真正下单的很少。这时候你盯着 TPS 看，会觉得系统很闲，但其实 QPS 已经快把数据库连接池打满了。
我的建议：压测时，QPS 和 TPS 都要看。QPS 反映前端压力，TPS 反映业务处理能力。两者差距过大，说明系统在“空转”。
2. 响应时间：用户的“等待感”
响应时间，就是从用户发出请求到收到响应的时间。单位通常是毫秒。
这个指标最直观。用户点一下按钮，等多久才能看到结果？
我曾经优化过一个接口，响应时间从 200ms 降到 50ms。用户反馈说“感觉快了一倍”。其实只快了 150ms，但人的感知就是这么敏感。
响应时间通常分几个等级：
| 等级 | 响应时间 | 用户感受 |
|---|---|---|
| 优秀 | < 100ms | 瞬间响应 |
| 良好 | 100ms - 300ms | 稍有延迟 |
| 一般 | 300ms - 1s | 明显等待 |
| 差 | > 1s | 用户流失 |
注意：响应时间不是越短越好。我见过有人把响应时间压到 1ms，结果用了大量缓存，数据一致性全丢了。嗯，这里要权衡。
3. 并发用户数：系统的“承载能力”
并发用户数，指的是同一时刻有多少用户在使用系统。
注意，是“同一时刻”，不是“一天的总用户数”。很多人搞混这个。
我记得有一次帮一个电商平台做压测。对方说“我们有 100 万用户”，我说“那并发用户数呢？”他们答不上来。后来一测，并发用户数只有 2000。为什么？因为大部分用户是分散在不同时间访问的。
并发用户数跟 QPS 的关系：
- 并发用户数 = QPS × 平均响应时间
- 这个公式很实用。比如 QPS 是 1000，响应时间是 200ms，那并发用户数就是 200
避坑指南：我曾经犯过一个错误——把并发用户数设得特别高，结果系统直接挂了。后来才明白，并发用户数要逐步增加，找到系统的“拐点”。
4. 吞吐量：系统的“总工作量”
吞吐量，单位时间内系统处理的总请求数。可以是每秒、每分钟、每小时。
吞吐量跟 QPS 有点像，但范围更广。QPS 是每秒的查询数，吞吐量可以是任何单位时间内的任何操作。
举个例子。一个文件上传系统，QPS 可能只有 10，但吞吐量是 100MB/s。这时候你只看 QPS，会觉得系统很弱，但其实它干了很多“重活”。
我个人习惯这样看：
- 轻量请求：看 QPS
- 重量请求：看吞吐量（比如带宽、磁盘 IO）
5. 资源利用率：系统的“健康度”
资源利用率，就是 CPU、内存、磁盘、网络这些资源用了多少。
这个指标特别重要。为什么？因为很多性能问题，根源就是资源不够用了。
我遇到过最典型的情况：CPU 利用率 100%，但 QPS 上不去。一看，原来是代码里有个死循环。还有一次，内存利用率 90%，频繁 GC，响应时间从 50ms 飙到 2s。
资源利用率的健康范围：
| 资源 | 健康范围 | 危险信号 |
|---|---|---|
| CPU | < 70% | > 90% 持续 |
| 内存 | < 80% | > 90% 或频繁 GC |
| 磁盘 IO | < 60% | > 80% 或等待时间长 |
| 网络带宽 | < 50% | > 80% 或丢包 |
我的经验：压测时，一定要同时监控资源利用率。如果 QPS 上不去，但资源利用率很低，说明系统有瓶颈。如果资源利用率很高，QPS 也上不去，说明系统已经到极限了。
6. P99/P95 延迟：长尾问题的“照妖镜”
P99 延迟，就是 99% 的请求都在这个时间内完成。P95 同理。
为什么看这个？因为平均响应时间会骗人。
举个例子。100 个请求，99 个是 10ms，1 个是 10s。平均响应时间是 109ms，看起来还行。但 P99 延迟是 10s，说明有 1% 的用户体验极差。
我曾经优化过一个系统，平均响应时间 50ms，但 P99 是 5s。查了半天，发现是某个慢查询在高峰期触发了全表扫描。修复后，P99 降到 100ms，用户体验大幅提升。
P99/P95 的典型场景：
- P50：大部分用户的体验
- P95：少数用户的体验，通常能接受
- P99：极端用户的体验，必须优化
注意：P99 不是越高越好。我见过有人为了追求 P99 到 10ms，把系统架构搞得极其复杂，成本翻了好几倍。其实 P99 到 100ms 已经够用了。嗯，这里要务实。
知识体系结构图
下面这张图，把六个指标的关系画出来了。你可以看到，它们不是孤立的，而是互相影响的。
这张图你看懂了吗？中心是性能指标，六个指标围绕它展开。每个指标之间都有关系。比如并发用户数高了，响应时间就会变长；响应时间长了，QPS 就会下降。这就是为什么我说它们是一张网。
总结一下
六个指标，各有各的用处：
- QPS/TPS：看系统能处理多少请求
- 响应时间：看用户等多久
- 并发用户数：看系统能扛多少人
- 吞吐量：看系统干了多少活
- 资源利用率：看系统健康不健康
- P99/P95：看有没有“拖后腿”的请求
记住，压测不是跑个脚本就完事了。你得会看指标，会分析，会定位问题。这才是真本事。
好了，这一章就到这里。下一章我们聊聊压测工具的选择和使用。到时候见。