Netty TrafficCounter

Question

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

2014-10-28 16:57:50,099计时器-4 INFO PerfLogging 130 - Netty流量统计系统TrafficShaping，具有写入限制:0读限制:0和计数器:监视器ChannelTC431885482当前速度读取: 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 226-39843-MTY6NDU6NDU6NTAvMDAwMDAW TrafficShaping，写入限制:0读限制:0和计数器:监视ChannelTC385810078当前速度读取:0 KB/s，写入: 3049 KB/s当前读取:0 KB 当前写入: 66837 KB

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

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

Answer 1

斯科特是对的，有一些修正，也考虑到了这一点。

一些解释：

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

1. proposed writes which are not yet sent but before the fix taken into account in the bandwidth (lastWriteThroughput) and in the current write (currentWrittenBytes)
2. real writes when they are effectively pushed to the wire

​

目前的问题是，currentWrittenBytes可能比真正的写入要高，因为它们大多是在将来排定的，因此它们依赖于作为写入事件源的处理程序的写入速度。在修复之后，我们将更加精确地确定什么是“提议/计划”以及什么是真正的“发送”：

1. 在lastWriteThroughput和currentWrittenBytes中考虑到的拟议写入
2. 当写入发生在线路上(至少在管道上)时，在realWriteThroughput和realWrittenBytes中考虑到真正的写操作。

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

• 带宽(总体平均和流量控制)是根据30(读或写)来计算的。
• 每隔30分钟，“小”计数器重置为0，而累积计数器则不会:如果使用累积计数器，则应看到接收/发送的字节几乎相同，而“小”计数器(currentXxxx)每30分钟重置为0。

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

例如，所看到的差异可能是因为发送方的30s事件与接收方的30s事件没有“同步”(而且不应该是同步的)。因此，根据您的数字:当接收方(read)使用30s事件重置其计数器时，作者将在稍后(24,010 KB)重置自己的计数器8s。