上线前压测，报告写平均响应 80ms、TPS 1200，评审会上大家都点头。上线第一天晚高峰就 502，值班的人一脸懵。

平均值是最会骗人的指标。1% 的请求卡十秒，平均也只抬几十毫秒，可用户体验就是转圈，最后超时。

该看哪几个数

  • TPS 和 QPS：每秒处理量，要写清是单接口还是整条链路
  • P95 和 P99：长尾真相，SLA 一般写 P99 小于 500ms
  • 错误率：非 2xx 的比例，压测里最容易被忽略
  • 资源水位：CPU、内存、连接数、GC 次数

工具和压法

单接口用 wrk -t4 -c200 -d60s --latency，轻、够用；要串登录、取 token、做参数关联就上 JMeter；写复杂场景用 locust，Python 脚本好维护。

压测机别和被压服务放同一台，压测机自己先跑满，测出来的是它的瓶颈。看 top 里 si 和 wa 两列，网络中断和磁盘等待高，说明压测机扛不住了。

几个常见误区

只用固定参数压同一个 key，缓存全命中，数据好看，上线一有冷数据就崩。要按真实比例造热点和长尾。

连接池只配 20，压测并发 500，多出来的全在排队，测到的是等待时间，不是处理能力。压之前先核对池子大小和数据库最大连接数。

压测时间太短也不行。跑 60 秒看不出内存泄漏和 GC 抖动，至少 10 分钟，盯着曲线有没有缓慢上扬。

还有一块常被跳过：数据要能代表生产。拿测试库那几百行数据压出来的曲线，跟线上没关系，索引也不一样。能脱敏同步一份生产数据最好；不能的话至少造到同一数量级，索引建全。

结论要带前提

多少数据量、多少并发、持续多久，这三样不写，TPS 数字就是空的。同样的系统，一万行数据能跑 3000，一千万行只剩 300，都很正常。