网络流量计数器

Question

我目前正在使用 io.netty.handler.traffic.ChannelTrafficShapingHandler 和 io.netty.handler.traffic.TrafficCounter 来测量 netty 客户端和服务器的性能。我一直看到服务器上的当前写入值和客户端上的当前读取值存在差异。考虑到写入/读取 KB/s 始终接近匹配，我该如何解释这种差异。

2014-10-28 16:57:50,099 [Timer-4] INFO PerfLogging 130 - Netty Traffic stats TrafficShaping with Write Limit: 0 Read Limit: 0 and Counter: Monitor ChannelTC431885482 Current Speed Read: 3049 KB/ s，写入：0 KB/s 当前读取：90847 KB当前写入：0 KB

2014-10-28 16:57:42,230 [ServerStreamingLogging] 调试 c.f.s.r.l.ServerStreamingLogger:115 - 流量统计 WKS226-39843-MTY6NDU6NTAvMDAwMDAw TrafficShaping with Write Limit: 0 Read Limit: 0 and Counter: Monitor ChannelTC385810078 Current Speed Read: 0 KB /s，写入：3049 KB/s 当前读取：0 KB 当前写入：66837 KB

客户端和服务器之间是否存在某种压缩？

我可以看到我的客户端值大约是 3049 * 30 = 91470KB，其中 30 是计算累积数字的秒数

Answer 1

Scott 是对的，有一些修复也考虑到了这一点。

一些解释：

• read实际上是真正的读取带宽和读取字节数（因为系统不是读取接收的来源）

• 对于写事件，系统是它们的来源并管理它们，所以有2种写（将在下一个修复中）：

  1. 在带宽 (lastWriteThroughput) 和当前写入 (currentWrittenBytes) 中考虑修复之前尚未发送的建议写入
  2. 当它们被有效推送到线路时的真实写入

目前的问题是 currentWrittenBytes 可能高于实际写入，因为它们大多是在未来安排的，因此它们取决于作为写入事件来源的处理程序的写入速度。 修复后，我们将更准确地确定“建议/计划”和真正“发送”的内容：

1. 考虑到 lastWriteThroughput 和 currentWrittenBytes 的建议写入
2. 当写入发生在线路上（至少在管道上）时，考虑到 realWriteThroughput 和 realWrittenBytes 的实际写入操作

现在有第二个元素，如果你将 checkInterval 设置为 30s，这意味着如下：

• 带宽（全局平均值和流量控制）是根据这 30 秒（读取或写入）计算的
• “小”计数器每 30 秒重置为 0，而累积计数器则不会：如果使用累积计数器，您应该看到接收/发送的字节数应该几乎相同，而“小”计数器每 30 秒重置一次(currentXxxx) 重置为 0

此 checkInterval 的值越小，带宽越好，但不能太小以防止过于频繁的重置和带宽计算上的线程活动过多。一般来说，默认 1s 是相当有效的。

所看到的差异可能是因为发送方的 30 秒事件未与接收方的 30 秒事件“同步”（并且不应如此）。因此，根据您的数字：当接收器（读取）使用 30s 事件重置其计数器时，写入器将在 8 秒后重置其自己的计数器（24 010 KB）。