延迟与负载的关系
把延迟指标与请求量、连接数按同一时间轴叠放，就能看出延迟是否由容量驱动。延迟随负载呈线性上升，通常是排队饱和的信号；延迟与负载脱钩，更可能是外部依赖或链路出了问题。这个判断决定了后面该扩容量还是去查依赖，方向选错会浪费大量时间。
基本信息
| 方法 | 时间轴叠图加相关系数 |
|---|---|
| 横轴 | 统一时区的时间 |
| 两条曲线 | 请求量或并发数、延迟 P95 |
| 干扰因素 | 周期性任务造成的假相关 |
典型使用场景
- 判断延迟上升是容量问题还是依赖问题
- 为大促前的扩容决策提供依据
- 解释「扩容后延迟没降」的原因
- 区分瞬时尖峰与持续漂移
- 与限流、熔断策略配合评估系统韧性
叠图口径
叠图口径
tshark -r a.pcap -q -z io,stat,10
# 抓包侧按 10 秒聚合看流量节奏，与监控平台的 P95 曲线对齐
tshark -r a.pcap -q -z conv,tcp | head -20
# 看会话分布，确认并发是否与延迟同步变化
# 对齐时先统一时区与采样粒度，分钟级监控与秒级抓包不能直接叠现象判读
| 现象 | 判读 | 处理方向 |
|---|---|---|
| 延迟随负载线性上升 | 排队趋于饱和 | 扩容或限流 |
| 延迟上升但负载不变 | 外部依赖或链路问题 | 查下游与网络 |
| 延迟与负载同步回落 | 正常削峰过程 | 无需处理 |
| 延迟出现尖峰后自恢复 | 瞬时抖动 | 看是否偶发并记录 |
定时任务会制造假相关：整点的批量作业会同时抬高请求量与延迟，看起来像容量问题，其实是任务叠加。分析前先把已知周期剔除，再看剩余部分的相关性。
相关不等于因果。要确认谁先动：是负载先升还是延迟先升，这个顺序决定归因方向。只看相关系数容易得出相反结论，尤其是采样粒度较粗的时候。
排查顺序
- 先统一时区与采样粒度，确认两条曲线可比较
- 剔除已知周期性任务的影响
- 看变化顺序，确认谁是先动的一方
- 结合资源指标（CPU、连接数、队列长度）判断是否真的接近饱和
- 扩容后复测同一口径，验证结论是否成立