压测报告写着 QPS 3000，老板觉得够用了。上线后晚高峰页面一直转圈，监控里 RT 从 80 毫秒涨到 2 秒，QPS 反而掉到 800。

qps 是每秒请求数

它只数请求，不管一个请求里干了多少事。TPS 按事务算，一个下单可能包含好几个请求。并发数是同一时刻在处理的数量，和 QPS 不是一回事。三者关系大概是 QPS 等于并发数除以平均响应时间，响应时间用秒，这就是排队论里的利特尔法则。

压测工具怎么用

wrk -t4 -c100 -d30s 加地址，四个线程、一百个连接跑三十秒；ab -n 10000 -c 100 更简单但没有长连接；JMeter 看聚合报告的 90% 和 99% 线。压测机和被测机别在同一台，否则测的是本机 CPU。测之前把日志级别调低，不然磁盘先扛不住。

qps 高但用户还是卡

平均值会把长尾盖住。一百个请求里九十九个 50 毫秒，一个 5 秒，平均下来仍然好看，用户感知的却是那个 5 秒。要看 P95、P99 和错误率。再往下查连接池够不够、有没有锁等待、GC 停顿、下游超时、带宽打满。

容量怎么估

峰值 QPS 乘单请求耗时，得到需要的并发处理能力，再留两倍余量。比如峰值 2000 QPS、单请求 100 毫秒，理论上要 200 个并发，实际按 400 准备。数据库连接数别跟着线性加，连接太多反而更慢。

报告里还要看什么

错误率超过 1% 就说明压测已经失真，后面的 QPS 没有意义。再看带宽和 CPU 是否先到瓶颈，磁盘 IO 等待高不高。单机 QPS 好看，数据库是单点，整体容量还是上不去。

压测数据别只看峰值

持续压十分钟和跑三十秒，结果可能差一倍。缓存预热、连接建立、GC 周期都会影响曲线。看 QPS 随时间的变化，平稳才算过，前期高后期掉说明有资源泄漏。

QPS 是个入口指标，不是结论。把它和 P99、错误率放一起看，才知道系统到底稳不稳。