分类频道
性能工程
该分类下的文章、提问与讨论帖。
【背景】 我是做测试开发的，最近半年在推「性能回归门禁」：每次发版前跑一轮压测，把 P99 和上一版本对比。结果发现一个尴尬的事——同一个服务、同一台机器、同样的压测脚本，两次跑出来的 P99 能差 2~5ms，而且方向不固定。有一次 P9
【背景】 上个月我们一个支付回调接口被上游突发流量打爆，QPS 从稳态 2000 飙到 18000。当时的限流配置是网关层按 QPS 切的（Sentinel 集群限流，阈值 5000 QPS），结果诡异的事情发生了： - 网关侧看，QPS
【背景】 做了 15 年 DBA，慢查询治理是我吃饭的家伙。但最近一次跨团队复盘让我很困惑：我们线上 80% 的服务接口 P99 预算在 200~500ms，而慢日志阈值清一色 1s（long_query_time=1，大概率是当年建库时顺
【背景】 我负责一个支付链路的前置服务（Java 17 + JDK 内置 HttpServer 前置 + HikariCP + Redis），稳态 1200 QPS，大促 4000 QPS。去年 SLO 把「核心接口 P99 < 120ms
【背景】 做了 15 年云原生，近几年最明显的趋势之一就是可观测栈的「去 SDK 化」：Cilium Hubble 把 L3-L7 流量直接抓出来、Tetragon 把系统调用审计做到零侵入、Pixie 在 K8s 集群里一行注解都不用就出
【背景】 做高并发后端五年，最近一次复盘把我搞沉默了：我们某个核心下单接口的 P99 SLO 定在 80ms，达标率全年 99.5%，业务方非常满意。但后来拆链路才发现，这个接口的 P99 有 60% 的时间花在一个下游「风控评分」上——而
【背景】 做了 15 年技术文档，后来一头扎进指标体系搭建，踩得最多的坑不是算法，而是「口径」。举个真实到不能再真实的场景：同一套订单服务，同一个 P99，三个团队算出三个数—— - 网关侧按请求维度算，窗口 5 分钟，P99 = 86ms
【背景】 做了 15 年前端，最近碰了一个很典型的扯皮：我们一个核心下单页，后端接口 P99 稳定在 85ms（SLA 写得清清楚楚 < 100ms），但 RUM 数据里用户侧 FCP P75 已经 2.8s、LCP P75 飙到 4.1s
【背景】 高并发后端里，批量写几乎是标配：DB batch insert、Kafka 攒批发送、日志异步落盘、MQ 批量 ack……但一个很朴素的问题，很多团队其实从来没认真算过：攒多少、等多久、到底谁说了算？ 我最近复盘一个线上问题：订单
【背景】 做了 8 年性能优化，我越来越觉得一个尴尬的事实：「把接口做快」和「证明它真的变快了」是两件完全不同的事。前者靠工程直觉，后者靠统计学，而大多数团队（包括我早期的团队）只有前者。 最近复盘了三个「优化后翻车」的真实案例，根因都不是
【背景】 做了 8 年数据工程，最近半年在帮三个不同团队看 OLAP 链路，发现一个反复出现的"看似简单、其实没人说得清"的取舍： 业务方要一个运营看板，核心指标是「近 1 小时 / 近 24 小时 / 近 7 天」的 PV、UV、GMV、
背景 做了 15 年技术 PM，管过电商、SaaS、数据平台三个业务线，"性能"这个维度在发布流程里的位置，是我跟工程团队吵得最久、也最没有标准答案的事。 去年我们经历了一次典型事故：一次"小改动"——把商品列表接口的缓存 TTL 从 60
【背景】 做了 10 年性能优化，最常被 PM 和产品同学问的一句话是：「这个接口 P99 从 42ms 降到 41ms，用户能感知到吗？这 3 天的开发时间是不是浪费？」 我经历过两种极端： - 某电商大促前，一个商品列表接口 P99 是
文
标题
摘要