优化前后怎么验证
时延优化最容易犯的错误是改完之后只测一个指标就宣布成功。稳妥做法是改动前后按同一口径各测一轮，覆盖五组数据：延迟分布、重传与零窗次数、吞吐、CPU 与中断分布、业务错误率，任意一项明显恶化都要回滚评估。回滚阈值必须在动手之前定义清楚，例如某个分位数恶化超过预设比例就立即回滚。观察窗口也要覆盖完整的业务周期，只测几分钟很容易错过高峰期才暴露出来的问题。
基本信息
| 输出 | 前后对照表与明确的回滚阈值 |
|---|---|
| 必测指标 | 延迟分位数、重传率、吞吐、资源占用、业务错误率 |
| 观察窗口 | 覆盖完整业务周期并包含高峰时段 |
| 基线要求 | 改动前采集，事后补测不可靠 |
| 参照依据 | RFC 6349（网络路径性能测试方法） |
典型使用场景
- 变更验证：每次调优都按同一清单确认没有引入回退
- 回滚决策：把恶化阈值提前写下来，避免临场争论
- 高峰覆盖：确认观察窗口包含业务高峰时段
- 多指标交叉：单项改善但其他项恶化时按整体判断
- 变更留档：把前后数据与配置一起归档
验证清单
验证清单
# 1) 同窗口同负载的延迟分位数
# 2) 重传率与零窗次数
# 3) 吞吐与有效带宽
# 4) CPU 与中断分布
# 5) 业务错误率与超时率清单与回滚
| 项目 | 采集要求 | 回滚条件 |
|---|---|---|
| 延迟分位数 | 同负载同窗口 | 恶化超过预设比例即回滚 |
| 重传与零窗 | 按方向分别统计 | 明显上升则回滚 |
| 吞吐 | 与基线同条件 | 提升不明显则评估保留价值 |
| 资源占用 | CPU 与中断分布 | 显著上升需要权衡 |
| 业务指标 | 错误率与超时率 | 任一项恶化立即回滚 |
回滚阈值要定义成可判定的数字，例如某一分位数恶化超过两成即回滚；临场讨论容易受主观判断影响。
改动前后使用同一套采集脚本与同一个抓包点，才能保证对比结果可信，否则统计口径变化本身就会制造出假差异。