延迟分解怎么做
延迟分解把端到端耗时拆成各段：排队等待（线程池、连接池、消息队列）、业务计算、序列化、网络往返、数据库查询与下游 RPC。做法是为每段单独计时，而不是把除业务代码之外的耗时都算进“应用耗时”。分解的价值在于排序：通常只有一到两段占据主要份额，先处理占比高且可优化的那一段，收益远大于在非瓶颈环节做局部优化。
基本信息
| 分段 | 网关排队、应用计算、序列化、网络往返、数据库与下游 |
|---|---|
| 手段 | 分布式追踪逐段计时；线程池与连接池等待单独统计 |
| 归因 | 先看占比与分位，再决定优化对象 |
| 口径 | 各段之和要能解释端到端耗时，存在缺口说明埋点缺失 |
典型使用场景
- 接口变慢排查：确定是自身计算、数据库还是下游引起
- 容量规划：按各段耗时与增长趋势判断资源瓶颈
- 优化效果验证：改造后看目标段占比是否下降、总延迟是否改善
- 跨团队归因：用分段数据把问题定位到具体服务或依赖
- SLO 监控：按段设置预算与告警，早于端到端指标发现问题
分解表示例（单请求）
分解表示例（单请求）
网关排队 12ms
线程池等待 8ms
业务计算 35ms
序列化与网络 9ms
数据库查询 45ms（其中锁等待 15ms）
下游 RPC 60ms
合计 169ms（对应 P99 249ms）
先处理占比高且可优化的段，如锁等待与下游 RPC分段与观察手段
| 分段 | 怎么测 | 常见误判 |
|---|---|---|
| 线程池等待 | 池等待时间单独埋点 | 混入业务耗时，优化方向错误 |
| 连接池获取 | 池获取耗时与超时计数 | 被当作数据库慢，实际是池不够 |
| 数据库查询 | 慢查询日志与追踪段结合 | 只看平均，锁等待在分位里才明显 |
| 下游 RPC | 追踪段与对端指标对照 | 只看自身计时，忽略对端排队 |
| 网络与序列化 | 框架内置指标或对照测试 | 与计算耗时混在一起无法区分 |
使用要点
- 排队等待（线程池、连接池、队列）要单独埋点，避免混入业务耗时
- 按分位而非均值分解，关注 P99 的主要贡献段
- 各段之和与端到端对比：出现显著缺口说明还有未埋点的环节
- 改造后复测同一分段口径，确认收益来自目标段而不是噪声
- 把分解结果与性能预算对照，超支的段优先治理
排队等待常被计入应用耗时：池等待与调度延迟要单独埋点，否则优化方向会被误导，出现“优化了业务代码但延迟没变”的情况。
只看均值做分解会得出错误的优先级：长尾请求的主要贡献段可能与均值完全不同，容量与优化决策都应按分位来做。