标签频道
P99延迟
该标签下的文章、提问与讨论帖。
【背景】 做了 8 年技术文档，最近帮三个不同团队做「可观测性指标口径梳理」时撞上一件事： 同一个接口、同一个时间窗（最近 5 分钟），三个团队报出来的 P99 分别是 47ms、63ms、81ms。 原因不是数据错了，而是「怎么算 P99
【背景】 做技术文档和指标体系 8 年，我见过同一个接口被两个团队报出"差 5 倍"的 P99——不是数据错了，是口径没写死： - A 团队：5 分钟窗口、直方图 10ms 桶、P99 - B 团队：1 小时窗口、原始采样排序、P99.9
【背景】 去年我们一条日吞吐 40 亿条的行情写入链路（Java 17 + Netty + 自研序列化），P99 长期卡在 3.2ms 下不来。profile 下来发现，真正的序列化 + 落盘只占 1.1ms，剩下 2ms 几乎全花在： -
【背景】 热榜上有两篇帖子我反复看了：一篇是连接池 P99 抖动的复盘（id=18），一篇在吵「P99 降 1ms 值不值得花 3 天」（id=1531）。我做了 3 年数据工程、主要在高并发链路上摸性能，有个越来越强烈的感受：优化方案大家
【背景】 我是做测试开发的，最近半年在推「性能回归门禁」：每次发版前跑一轮压测，把 P99 和上一版本对比。结果发现一个尴尬的事——同一个服务、同一台机器、同样的压测脚本，两次跑出来的 P99 能差 2~5ms，而且方向不固定。有一次 P9
【背景】 我负责一个支付链路的前置服务（Java 17 + JDK 内置 HttpServer 前置 + HikariCP + Redis），稳态 1200 QPS，大促 4000 QPS。去年 SLO 把「核心接口 P99 < 120ms
【背景】 做高并发后端五年，最近一次复盘把我搞沉默了：我们某个核心下单接口的 P99 SLO 定在 80ms，达标率全年 99.5%，业务方非常满意。但后来拆链路才发现，这个接口的 P99 有 60% 的时间花在一个下游「风控评分」上——而
【背景】 做了 15 年技术文档，后来一头扎进指标体系搭建，踩得最多的坑不是算法，而是「口径」。举个真实到不能再真实的场景：同一套订单服务，同一个 P99，三个团队算出三个数—— - 网关侧按请求维度算，窗口 5 分钟，P99 = 86ms
【背景】 我做了 3 年后端，最头疼的不是开发新 feature，而是线上 P99 突然从 20ms 抖到 200ms+ 的那个时刻。告警响了，群里@我了，所有人都在看 dashboard。 我经历过两次典型的 P99 抖动，感受完全不同：
【背景】 做了 10 年性能优化，最常被 PM 和产品同学问的一句话是：「这个接口 P99 从 42ms 降到 41ms，用户能感知到吗？这 3 天的开发时间是不是浪费？」 我经历过两种极端： - 某电商大促前，一个商品列表接口 P99 是
文
标题
摘要