标签频道
性能优化
该标签下的文章、提问与讨论帖。
discussion
P99 达标之后，我们到底该不该继续追 P999？聊聊尾延迟优化的「收益拐点」
背景 做了 8 年性能优化，我发现团队里有个挺普遍的现象：P99 从 500ms 压到 100ms 的过程，大家干劲十足；可一旦达标，再往下压 P999，往往就没人愿意碰了。原因很现实——P999 的毛刺往往来自 GC、page cache
«一个 8 年性能老兵的线上复盘。不吹概念，只讲我真实排查过的一类"看不见"的延迟。» 一、现象与背景：一个 40ms 的幽灵 2024 年 3 月，某电商订单链路（下单 → 库存 → 价格 → 风控 → 支付路由，共 12 跳同步 RPC
discussion
异步化是性能优化的万能药，还是最贵的一笔复杂度税？
先抛一个我 2021 年踩过的真实案例，再讲我的困惑，想听听大家的判断。 【背景案例】 某电商的"下单成功页"需要聚合 4 个下游：库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms，P99 飙到 480ms（物流预
«结论先行："useTransition" 不是加上去就完事的。我们一个 B 端后台（React 18.2 + Vite 5 + TypeScript），给搜索框加 "useTransition" 后 INP P75 只从 900ms 降到
discussion
单表从 1 亿行到 10 亿行：升配、读写分离、分区、分库分表，你的优先级到底怎么排
背景 做了 10 年 DBA，被业务方问得最多的一个问题就是："我们的表要爆了，下一步该怎么办？" 每次问这话的时候，团队里通常已经开始在四条路线之间摇摆： 1. 垂直扩容：升配，更大规格的实例（vCPU / 内存 / SSD 升级一档），
一、现象：一个「越用越卡」的 B 端后台，一周 11 单工单 我们一个运营中台（React 18.2 + Ant Design 5.12，Vite 4 构建），运营同学连续两周反馈同一句话：「早上还好，下午用两小时就开始卡，刷新一下就恢复」
指标加速层选型：现算、物化视图、实时流，一次把该选哪个讲清楚 «本文站在「指标体系搭建」视角，对比三种指标加速方案的延迟、成本与口径一致性，给出可复现的选型决策。» 一、现象与背景 接手一个 B 端数据产品后，第一周就撞上一堵墙：核心看板的
结论先行 INP（Interaction to Next Paint）在 2024 年 3 月正式取代 FID 成为 Core Web Vitals 的交互指标后，我们一个 B 端中台的 INP P75 从 480ms 一路恶化到 720m
discussion
性能优化第一刀，该先砍「单次成本」还是先买「更多机器」？聊聊扩容与重构的排序
背景 做了 8 年性能优化，带过的团队里反复出现同一个争论：当 P99 开始劣化、业务方催得紧的时候，第一刀到底怎么砍？ 我手上有个不太夸张但很典型的案例：某交易链路 P99 从 180ms 涨到 650ms，QPS 只涨了 40%。两种方
现象与背景 Core Web Vitals 里最容易「背锅」的指标是 CLS（Cumulative Layout Shift，累积布局偏移）。我们一个电商商品详情页，Lighthouse 移动端跑分 CLS 一度到 0.45（Good 的门