性能监控

现象或背景：SQL 执行计划漂移，但不是参数没调对 有一条 SQL，执行计划漂移了，导致 P99 从 15ms 飙到 3.4s，但索引没变、SQL 文本没变，连 buffer pool 命中率也没掉。这种「执行计划漂移」比绝大多数「索引没建

【背景】 做了 5 年前端，最近半年被绩效指标绑死在「核心页面端到端 P99 ≤ 300ms」上。但每次复盘对不上号：后端 APM（SkyWalking + 自研埋点）显示核心查询接口 P99 是 85ms，前端 RUM（自研 SDK 基于

【背景】 做了 5 年前端，最近半年一直在推「前端可观测性」：从基础 JS 异常上报、白屏检测，到性能监控（LCP / INP / CLS）、资源加载瀑布图、异常聚类。团队里后端同学很自然地用 SLO + 错误预算来管理服务质量，我试着把同

【背景】 做了 10 年前端，最近半年把团队的前端可观测性链路（RUM + 错误上报 + 性能指标）重新梳理了一遍。最纠结的一件事是采样率到底怎么定。 我们的量级：核心页面 DAU 约 80w，日均 PV 约 400w，走的是自研上报 SD

背景 8 年前端，负责一个 B 端 SaaS（约 200 个路由、日活 3w+）的性能可观测。现状是双通道： - 合成拨测：固定机型/网络/地区，每天 4 轮，数据干净稳定，LCP P99 ≈ 1.8s； - RUM：全量会话采样 10%，

背景 热榜上 #1374 那个提问把后端「trace 三段加起来 80ms、网关却看到 2.4s」的缝隙讲得很透。我从前端这边看，类似的「口径对不上」每天都在发生，只是没人系统讨论： - 后端说「这个接口 P99 200ms 达标」； -

一、现象与背景：一个「下降 12%」的假胜利 去年我们给公司核心交易链路做了一轮 GC 调优 + 连接池扩容，上线后周报写的是漂亮数字：87 个接口的平均耗时从 287ms 降到 252ms，下降 12%，被当成季度技术亮点汇报。 直到两个

【背景】 我们是一个 React 18 + Webpack 5 的中后台 SPA，约 200 个路由、60+ 个三方 SDK（埋点、IM、风控、客服等）。今年开始把 Web Vitals 纳入稳定性大盘，INP 目标 < 200ms。 【现