Performance 网络流量计数器

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

2014-10-28 16:57:50099[Timer-4]信息性能记录130-净流量统计数据具有写入限制：0读取限制：0和计数器：监控通道TC431885482当前速度读取：3049 KB/s，写入：0 KB/s当前读取：90847 KB当前写入：0 KB

2014-10-28 16:57:42230[ServerStreamingLogging]调试c.f.s.r.l.ServerStreamingLogger:115-流量统计WKS226-39843-MTY6NDU6NTAVMDAW流量整形，写入限制：0读取限制：0，计数器：监控通道TC385810078当前速度读取：0 KB/s，写入：3049 KB/s当前读取：0 KB当前写入：66837 KB

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

---

我可以看到我的客户端值约为3049*30=91470KB，其中30是计算累积数字的秒数。Scott是对的，有一些修正也被考虑在内

一些解释：

• 读取实际上是实际读取带宽和读取字节数帐户（因为系统不是读取接收的来源）
• 对于写入事件，系统是它们的来源并对其进行管理，因此有两种写入（将在下一个修复中）：

• 在带宽（lastWriteThroughput）和当前写入（CurrentWriteNbytes）中考虑的修复之前尚未发送的建议写入
• 当它们被有效地推送到导线上时，real写入

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

建议的写入已考虑到lastWriteThroughput和CurrentWriteNbytes

当写入发生在线路上（至少在管道上）时，realWriteThroughput和RealWriteNbytes中考虑的实写操作

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

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

此检查间隔的值越小，带宽越好，但不能太小，以防止在带宽计算上进行过频繁的重置和过多的线程活动。通常，默认值为1是相当有效的

---

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

不确定这是否相关，但与代码的此区域相关的PRs打开了一堆。例如，谢谢你提供的信息，斯科特，谢谢你提供的详细信息，弗雷德里克。我将等待下一个netty版本。