ODT性能指标：延迟、吞吐量、抖动、丢包率、资源利用率

做ODT调优，不能光凭感觉。你得盯住五个关键指标——延迟、吞吐量、抖动、丢包率、资源利用率。这五个东西，就像一辆车的五个仪表盘。少看一个，都可能翻车。

我个人习惯，拿到一个ODT系统后，先看这五个指标散点图。哪个指标离红线最近，哪个就是优先要解决的问题。别上来就调参数，先搞清楚问题在哪。

1. 延迟 —— 快不快，用户说了算

延迟，说白了就是数据从发到收，花了多少时间。单位一般是微秒或毫秒。我在项目中遇到过，一个ODT拓扑里，延迟突然从50μs跳到500μs。查了半天，发现是某个中间节点缓存太小，流量一长就排队。

延迟一般包括三部分：传播延迟（物理距离）、传输延迟（带宽决定）、处理延迟（节点转发时间）。高负载下，处理延迟占比最大。

• 测量方式：ping、traceroute、或者更精确的硬件时间戳。
• 优化目标：不同场景不一样。比如实时音视频，要求端到端延迟<100ms；而大数据批处理，几百毫秒也能接受。

2. 吞吐量 —— 能扛多少活

吞吐量是单位时间内能处理的数据量，比如Mbps或每秒事务数。延迟低不代表吞吐高。你想想看，一条路再宽，如果每个车都慢吞吞，总流量也上不去。反过来，吞吐高不代表延迟低——有可能靠并行堆起来的。

我建议用压力测试来摸清ODT拓扑的吞吐上限。我记得有一次，拓扑看起来没问题，但压力一上来，吞吐就断崖式下跌。后来发现是某个节点的中断处理瓶颈。

• 测量方式：iperf、wrk、或业务层面的并发测试。
• 与延迟的关系：一般来说，负载越高，延迟越大。但好的ODT设计，能在接近吞吐上限时仍然保持较低延迟。

3. 抖动 —— 稳定比快更重要

抖动是延迟的波动程度。两个包，一个花了1ms，一个花了100ms，这系统就算平均延迟再低，用户也受不了。比如在线游戏里，角色瞬移就是抖动搞的鬼。

我建议关注抖动分布，而不是只看平均值。有时候系统看起来没问题，但抖动标准差很大。我曾经排查过一个抖动问题，最后发现是电源波动导致的时钟不稳。嗯，这里要注意，抖动可能来自硬件，可能来自软件，要一层层剥。

4. 丢包率 —— 一个包都不能少？

丢包率就是发送的包中，没到达的比例。丢一个包，可能引发重传，加剧延迟和抖动。TCP会感知丢包后降低发送速率，所以丢包率直接拖累吞吐。

现实中，有些链路丢包率超过1%就很明显了。我在项目中遇到过，某个节点CPU过载，开始丢包，整个系统性能像过山车。

• 测量方式：ping -c 1000 统计丢包，或用专门的探针。
• 优化目标：对可靠性要求高的场景，丢包率必须<0.01%。一般场景<0.1%勉强接受，超过1%需要紧急处理。

5. 资源利用率 —— 别让硬件当花瓶

资源利用率包括CPU、内存、带宽、队列深度、连接数等。利用率太低是浪费，太高是风险。我习惯设定水位线：比如CPU长期超过70%就该考虑扩容了。

资源利用率这个指标，容易被人忽略。你想想看，延迟、吞吐都正常，但某个节点的内存占用已经飙到95%，那下一个突发流量就可能炸。我建议持续监控，并设置告警。

各指标对比一览

指标	定义（一句话）	衡量单位	典型影响
延迟	数据从源到目的的时间差	μs / ms	影响交互体验
吞吐量	单位时间处理量	Mbps / TPS	影响系统容量
抖动	延迟的波动程度	ms（标准差或峰峰值）	影响稳定性，尤其实时业务
丢包率	丢失包占总发送包比例	百分比	触发重传，降低吞吐
资源利用率	硬件或软件资源占用程度	百分比	影响可靠性和扩展性

它们之间的关系

这五个指标互相牵连。你压延迟，可能就得牺牲吞吐或增加资源消耗。你提高吞吐，抖动和丢包率可能爬升。所以说，ODT调优是你中有我，我中有你。

下面这张图，把五个指标和它们的核心关系串了起来。你可以作为调优时的检查清单。

记得有一次，我帮一个客户调ODT参数。对方老说“带宽不够”，让我加吞吐。结果我一测，延迟都飘到2秒了，丢包率0.5%。后来我先把抖动压下来，丢包率降到0.01%，吞吐反而上去了。嗯，这就是指标的连锁反应。

总之，这五个指标是你做ODT调优的“五感”。缺一个，就像闭着眼睛开车。你得多维度地看，别迷信单指标。