性能压测核心指标详解
做性能压测这么多年，我最大的感悟就是：指标不是冷冰冰的数字，它们是系统的「体检报告」。很多团队一上来就盯着QPS猛冲，结果系统崩了都不知道为什么。今天我们就把这四个指标——QPS、响应时间、错误率、资源利用率——拆开揉碎了讲清楚。
为什么是这四个指标？
你可以把它们想象成汽车的四个仪表盘：
- QPS（每秒查询数）—— 速度表，看能跑多快
- 响应时间 —— 油门响应，踩下去多久才有反馈
- 错误率 —— 故障灯，有没有爆缸
- 资源利用率 —— 油温、水温、胎压，看哪个部件在扛不住
少了任何一个，你都没法精准定位性能瓶颈。我记得有一次帮客户压测，他们只报了QPS，说没问题。我上去一测，QPS确实达标，但响应时间已经飙到5秒了——用户早跑光了。
QPS — 吞吐量的硬指标
QPS就是每秒能处理多少个请求。公式很简单：
QPS = 总请求数 / 总时间（秒）实际压测时，我习惯看稳定QPS而不是峰值。为什么？因为系统可能刚启动时缓存没预热，前几秒数据不准确。我通常会让压测持续3-5分钟，取中间2分钟的平均值。
响应时间 — 用户体验的尺子
响应时间不能只看平均值。平均值会被少数慢请求拉高，但更可怕的是那些「尾巴」——P99延迟。我习惯看三个分位值：
| 指标 | 含义 | 典型阈值（仅供参考） |
|---|---|---|
| P50（中位数） | 50%的请求都在这个时间内完成 | < 200ms 优秀 |
| P95 | 95%的请求都能接受的速度 | < 1s 可接受 |
| P99 | 最慢的1%请求表现 | < 3s 否则需要优化 |
我见过很多团队只看平均值，P99烂到10秒还觉得自己系统没问题。说白了，那个最慢的1%用户，很可能就是你的付费用户。
错误率 — 系统的容忍线
错误率分两类：
- 协议层错误：HTTP 5xx、连接超时、断连
- 业务层错误：返回码非0、业务逻辑失败
压测时我建议把错误率和QPS画在同一张图里。当QPS接近极限时，错误率往往会突然飙升。我曾经遇到过，某系统在QPS 2000时错误率0.1%，QPS 2200时直接跳到15%——说明已经过载了。
我的经验是：错误率超过1%就必须停掉压测排查。继续加压只会让系统雪崩。
资源利用率 — 瓶颈探测器
看资源利用率不是为了看「用了多少」，而是为了找出短板。我习惯把四个主要资源列个表：
| 资源 | 理想范围 | 危险信号 |
|---|---|---|
| CPU | 70%～90% | >95% 持续 30 秒 |
| 内存 | 60%～80% | 接近100%或频繁GC |
| 磁盘 I/O | 队列长度 < 2 | iowait > 20% |
| 网络带宽 | 低于上限的 80% | 丢包率 > 0.1% |
注意：CPU不是越高越好。如果CPU长期跑在95%以上，响应时间会急剧恶化，因为排队时间变长了。我习惯留10%~15%的余量给突发流量。
它们之间如何互相影响？
这四个指标不是孤立的。我画了一张关系图，可以帮你快速理解：
从图中你能看到，这四个指标形成了反馈环路。我在压测时最关注的就是这个环路在哪一个环节断裂——通常是资源利用率先到达极限，然后响应时间飙升，接着错误率爆发，最后QPS断崖式下跌。
实战经验与避坑指南
最后，我建议每个团队在压测开始前，先定义好这四个指标的上限阈值。把它们写进压测脚本里，一旦触发自动告警甚至自动停止。这样你不在现场也能放心跑压测——嗯，这就是自动化压测的魅力。