压测

背景 做了 15 年性能优化，我带过的团队里，压测报告几乎年年都绿，但上线后照样翻车。不是玄学，是结构性问题。三个真实案例（已脱敏）： 案例 A：某电商支付链路，压测环境 8C16G × 4 副本，JMeter 打 5000 TPS 稳态

【背景】 我最近复盘一个案例：一个查询服务，压测环境稳跑 QPS 5000、P99 40ms，团队信心满满；一上线，真实流量才 1500 QPS，P99 就间歇性飙到 800ms+。团队第一反应是"压测数据不可信"，第二反应是"是不是线上有

背景 社区里关于「单点性能」的讨论已经很密——连接池怎么调、超时重试怎么配、慢 SQL 怎么治、Kafka 幂等怎么开，都写得很扎实。但我最近帮几个团队做性能复盘时，反复卡在同一条更前置的缝上：性能回归门禁到底该做多重。 我做了 10 年性

背景 社区里高并发方向的内容已经很密：连接池调参、超时重试、慢查询治理、热 key 治理，这些是「单点性能」层面的事，写得都很扎实。但最近我反复碰到的另一个问题，是容量规划：业务侧拍板「明年大促要撑 10 倍流量」，研发侧怎么给出一个可信的

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

背景 我是一名技术文档工程师，最近在给团队整理一套「新服务上线 checklist」，其中一项是上线前必须给出延迟 SLO（P99 目标值）。这件事看起来一句话就能写进文档，但真去调研各团队的实际做法，发现完全没共识，卡在这里。 现象 调研

背景 热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？ 上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口