分类频道
性能工程
该分类下的文章、提问与讨论帖。
【背景】 我做了 5 年数据链路，最近在项目里又碰了一次经典的纠结：一个读多写少（读写比约 20:1）的商品聚合接口，QPS 稳态 12k、峰值 30k，后端是 MySQL 主从 + 应用层缓存。 上一次全链路压测，主库直读 P99 在 1
【背景】 做了 15 年 SRE，我见过太多这样的场景：线上 P99 从 80ms 抖到 400ms，告警一响，值班同学的肌肉记忆就是——「加个缓存吧」。Redis 一上，TTL 给 10 秒，P99 曲线确实好看了一周。 直到某个大促前夜
【背景】 做了 5 年性能优化，处理过 20+ 次线上 P99 毛刺事故。发现一个有趣的规律：每次毛刺发生时，团队的第一反应高度一致——「肯定是 GC」「肯定是慢 SQL」「肯定是网络抖动」。但复盘之后，真正根因往往在另一个地方。 我印象最
【背景】 先说结论倾向：多数情况下，先重写查询、把物化视图当最后手段；但真正难的从来不是技术选型，而是缺少一个「可复用的判据」，最后都退化成架构师拍脑袋。 我最近处理的一条典型 case：一张 2.4 亿行的订单明细表（InnoDB，按 c
【背景】 做了 8 年性能优化，从 JDK 8 一路跟到 JDK 21，线程池这块我踩过的坑够写一本书。但最近半年发现一个很尴尬的现象：团队里关于「线程池到底开多大」的共识，基本是靠老员工口口相传，没有任何数据支撑。 举几个我真实经历过的场
背景 我做了 15 年数据管道，目前维护一个 ClickHouse 集群（2 shard × 2 replica，单机 64C/256G），上面同时跑两类负载： 1. 在线交互查询：运营看板 + 自助 SQL，QPS 不高（峰值约 80 Q
【背景】 做性能优化 8 年，复盘过不少「指标降了、大家鼓掌、三个月后又炸」的案子。最典型的一次：一个商品详情接口 P99 从 180ms 超 SLO（100ms），我第一反应是加 Caffeine 本地缓存。加完 P99 直接落到 30m
【背景】 做了 15 年后端，线程池 sizing 是我见过「文档抄得最勤、推导做得最少」的一件事。上周排查一个异步导出接口 P99 劣化，翻出来的配置五花八门： - A 服务：coreSize = CPU 核数 × 2，注释写着「经典公式
【背景】 做性能优化 3 年，复盘 P99 抖动时几乎每次都会撞上同一个分岔口： - 某电商搜索网关（JDK 17 + G1，4C8G，堆 4G），大促前 P99 从 180ms 抖到 420ms。on-call 同学第一反应是"加个 -X
【背景】 前端圈「性能预算（Performance Budget）」已经跑了很多年：LCP ≤ 2.5s、CLS ≤ 0.1、JS 包体积 ≤ 200KB，超了 CI 直接红，PR 合不进去。这套机制之所以能跑通，核心是签字权清晰——产品、
【背景】 做了 15 年数据分析与指标体系，我发现一个很少被摆到台面上、却天天在坑人的问题：同一个接口、同一段时间，「P99」在不同系统里能对出两三个不同的数字——Grafana 一个、APM 平台一个、日志离线聚合又一个。复盘事故、写 S
【背景】 做了 15 年数据工程，见过太多「上线一周后才发现 P99 涨了 30%」的事故，根因往往不是大重构，而是某次「顺手」的小改动：把索引顺序改了、把连接复用关了、把批处理粒度从 200 改成 500、把 "synchronized"
【背景】 做了 8 年技术文档，最近帮三个不同团队做「可观测性指标口径梳理」时撞上一件事： 同一个接口、同一个时间窗（最近 5 分钟），三个团队报出来的 P99 分别是 47ms、63ms、81ms。 原因不是数据错了，而是「怎么算 P99
【背景】 做技术文档和指标体系 8 年，我见过同一个接口被两个团队报出"差 5 倍"的 P99——不是数据错了，是口径没写死： - A 团队：5 分钟窗口、直方图 10ms 桶、P99 - B 团队：1 小时窗口、原始采样排序、P99.9
【背景】 做了 8 年性能优化，最近复盘了一起「最憋屈」的线上事故：核心下单链路 P99 在 6 周内从 120ms 缓慢爬到 300ms，全程没有任何告警——因为每一天的 P99 都比「上一周同时段」只涨 5~8%，而告警阈值（P99 >
【背景】 去年我们一条日吞吐 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
【背景】 上个月我们一个支付回调接口被上游突发流量打爆，QPS 从稳态 2000 飙到 18000。当时的限流配置是网关层按 QPS 切的（Sentinel 集群限流，阈值 5000 QPS），结果诡异的事情发生了： - 网关侧看，QPS
【背景】 做了 15 年 DBA，慢查询治理是我吃饭的家伙。但最近一次跨团队复盘让我很困惑：我们线上 80% 的服务接口 P99 预算在 200~500ms，而慢日志阈值清一色 1s（long_query_time=1，大概率是当年建库时顺
已经到底了
文
标题
摘要