压测 1000 QPS 时 P99 120ms，线上同 QPS 却飙到 350ms——这 3 倍差距到底差在哪？

背景

做了 10 年性能优化，带过的团队里有一个反复出现的"信任危机"：压测报告写得很漂亮，P50 / P99 都达标，但一上真实流量，P99 就翻 2~3 倍。不是每次都这样，但每次遇到，排查起来都很痛苦——因为压测数据"看起来是对的"，你很难质疑它。

我最近复盘了一个典型案例：一个商品详情接口，Spring Boot 3 + JDK 21（ZGC，-Xmx4g）+ MySQL 8 + Redis 7，部署在 K8s 4C8G Pod。

• 压测环境：wrk 打 1000 QPS，P50 = 18ms，P99 = 120ms，持续 30 分钟无抖动。
• 线上环境：同样 1000 QPS（峰值），P50 = 25ms，P99 间歇性飙到 340~500ms，每周 2~3 次，每次持续 20~40 秒。

两个环境的代码、配置、JVM 参数完全一致。差距不是"差一点"，是 3 倍。

常见分歧 / 几种解释

团队里对"为什么压测和线上差这么多"至少有四种主流解释：

1. 流量模式不同：压测是"均匀请求"，线上是"突发 + 长尾 + 混合路径"。1000 QPS 的压测里 90% 走缓存命中路径，线上可能 30% 走 DB 慢路径。→ 反驳：我们做了路径拆分压测，单路径 P99 都达标。
2. 下游抖动：线上依赖的 5 个下游服务（用户、库存、价格、推荐、风控）任何一个 P99 抖一下，串联起来就放大。→ 反驳：查了下游 SLO，同期都在 99.9% 以上。
3. 资源竞争：K8s 同节点混部了别的 Pod，CPU steal / 内存带宽 / 磁盘 IO 互相干扰。→ 反驳：做了独占节点，差距仍然存在。
4. JVM 冷态 / JIT / GC：压测 30 分钟里 JIT 充分编译、GC 平稳；线上流量有波峰波谷，JIT 反复 deopt、GC 频率变化。→ 反驳：ZGC 暂停时间 < 1ms，不太可能是 300ms 量级的毛刺。

我的倾向

我倾向于第 1 种 + 第 2 种的组合，而且核心不是"哪个下游慢"，而是请求的"形状"不同：

• 压测工具（wrk / JMeter）发出的请求是"同质"的——同一组入参、同一条代码路径、同一个下游调用组合。
• 线上 1000 QPS 是"异质"的——不同用户、不同商品、不同缓存命中率、不同的下游调用子集。P99 是第 99 百分位，它捕捉的恰恰是"那 1% 最慢的请求"，而这些请求往往走了压测里根本没覆盖到的路径。

所以我的经验是：压测报告里 P99 达标，只能说明"被覆盖到的路径"的 P99 达标；没覆盖到的路径，压测数据是盲区。

具体做法：

• 压测时不要只打"黄金路径"，要把 top 5 慢路径（按线上 trace 采样）单独拎出来压；
• 压测的入参分布要从线上 trace 里采样，而不是手写 10 个固定入参；
• 压测时把下游 mock 成"真实 P99 延迟"（从 APM 数据取），而不是固定 5ms。

想听大家的

1. 你们团队的压测和线上 P99 差距一般多大？2 倍、3 倍、还是 5 倍以上？
2. 你们怎么定位"压测没覆盖到的慢路径"？是靠 APM trace 采样、日志 grep，还是"等它出问题再查"？
3. 有没有人试过"把线上流量镜像到压测环境"（traffic replay）？效果如何，坑在哪里？
4. 一个更尖锐的问题：如果压测永远测不出线上的 P99 毛刺，那压测的"达标"到底意味着什么？是"可以上线"的信号，还是只是"还没测到"？

欢迎带真实数据来聊，最好有具体的 P50 / P99 数字和排查过程。空谈方法论的咱们另开一帖。