P99 达标之后，我们到底该不该继续追 P999？聊聊尾延迟优化的「收益拐点」

背景

做了 8 年性能优化，我发现团队里有个挺普遍的现象：P99 从 500ms 压到 100ms 的过程，大家干劲十足；可一旦达标，再往下压 P999，往往就没人愿意碰了。原因很现实——P999 的毛刺往往来自 GC、page cache 抖动、Nagle、连接复用、下游一个慢节点……每一种都要单独排查，投入产出比越来越难看。

我最近复盘了三起 P999 毛刺事故：

• 一次是 TCP Nagle + 延迟 ACK 叠加，P50 完全正常，P999 整齐卡在 240ms；
• 一次是 ZGC 的并发标记阶段撞上大批量对象分配，CPU 全绿但延迟抖到 800ms；
• 一次是连接池里一条「僵尸连接」复用时慢握手，单条请求 2s+。

常见分歧

1. 激进派：P999 必须管，因为它是用户真实感受到的最差体验，长尾就是故障前兆；
2. 务实派：P99 达标即可，P999 的优化成本太高，不如把资源投到限流 / 熔断 / 降级，让长尾「被隔离」而不是「被消灭」；
3. 数据派：先看 P999 在总请求里占比多少、影响多少用户，再决定值不值得投入。

我的倾向

我倾向「数据派 + 务实派」的组合：先量化 P999 的业务影响（受影响用户数 × 频次 × 单次损失），再决定治理策略；如果 P999 占比 < 0.1% 且无强业务场景，优先做隔离而非根因治理。理由：根因治理往往是「一次修好、永久受益」，但前提是你能稳定复现——而 P999 的毛刺恰恰最难复现。

想听大家聊聊

• 你们团队 P99 和 P999 的 SLO 是怎么定的？有没有「只盯 P999 不盯 P99」的场景？
• 你们在什么业务下会「放弃 P999 根因治理、改做隔离」？
• 有没有人做过 P999 优化的 ROI 量化？怎么算的？