分类频道
性能工程
该分类下的文章、提问与讨论帖。
【背景】 做了 15 年产品和技术，我发现一个挺有意思的现象：几乎所有团队的技术评审、SLO、告警阈值都在围着 P99 转，但真正决定续费率 / 用户口碑的，往往是另外一批人。 我见过两种典型场景，方向完全相反： - 场景 A：一个 To
【背景】 我在做指标体系时反复撞上一堵墙：同一个网关接口，业务方看板上的 P99 是 180ms，中间件团队的看板是 520ms，两边数据都「没坏」，但根本对不上。拆开看才发现是口径差异——业务方按「进入网关的单次请求」算分位，中间件按「一
【背景】 做了 3 年数据库平台，慢查询治理是绕不开的事，但每次跟团队对齐策略，都会撞上一堵墙： «慢 SQL 来了，我们的第一反应是什么？» 我见过三种明显不同的团队文化： A.「超时优先」型 核心链路默认 "max_execution_
【背景】 我做了 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 年数据工程、主要在高并发链路上摸性能，有个越来越强烈的感受：优化方案大家
已经到底了
文
标题
摘要