CODEWITHSUNDEEP
performancenetty
TFlanagan
TFlanagan

Reputation: 13

Netty TrafficCounter

I am currently using the io.netty.handler.traffic.ChannelTrafficShapingHandler & io.netty.handler.traffic.TrafficCounter to measure performance across a netty client and server. I am consistently see a discrepancy for the value Current Write on the server and Current Read on the client. How can I account for this difference considering the Write/Read KB/s are close to matching all the time.

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, Write: 0 KB/s Current Read: 90847 KB Current Write: 0 KB

2014-10-28 16:57:42,230 [ServerStreamingLogging] DEBUG c.f.s.r.l.ServerStreamingLogger:115 - Traffic Statistics WKS226-39843-MTY6NDU6NTAvMDAwMDAw TrafficShaping with Write Limit: 0 Read Limit: 0 and Counter: Monitor ChannelTC385810078 Current Speed Read: 0 KB/s, Write: 3049 KB/s Current Read: 0 KB Current Write: 66837 KB

Is there some sort of compression between client and server?

I can see that my client side value is approximately 3049 * 30 = 91470KB where 30 is the number of seconds where the cumulative figure is calculated

Upvotes: 0

Views: 1420

Answers (1)

Frederic Brégier
Frederic Brégier

Reputation: 2206

Scott is right, there are some fix around that are also taken this into consideration.

Some explaination:

  • read is actually real read bandwidth and read bytes account (since the system is not the origin of read reception)

  • for write events, the system is the source of them and managed them, so there are 2 kinds of writes (and will be in the next fix):

    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

Currently the issue is that currentWrittenBytes could be higher than real writes since they are mostly scheduled in the future, so they depend on the write speed from the handler which is the source of the write events. After the fix, we will be more precise on what is "proposed/scheduled" and what is really "sent":

  1. proposed writes taken into consideration into lastWriteThroughput and currentWrittenBytes
  2. real writes operations taken into consideration into realWriteThroughput and realWrittenBytes when the writes occur on the wire (at least on the pipeline)

Now there is a second element, if you set the checkInterval to 30s, this implies the following:

  • the bandwidth (global average and so control of the traffic) is computed according to those 30s (read or write)
  • every 30s the "small" counters are reset to 0, while the cumulative counters are not: if you use cumulative counters, you should see that bytes received/sent should be almost the same, while every 30s the "small" counters (currentXxxx) are reset to 0

The smaller the value of this checkInterval, the better the bandwidth, but not too small to prevent too frequent reset and too many thread activities on bandwidth computations. In general, a default of 1s is quite efficient.

The difference seen could be for instance because the 30s event of the sender is not "synchronized" with 30s event of the receiver (and shall not be). So according to your numbers: when receiver (read) is resetting its counters with the 30s event, the writer will resetting its own counters 8s later (24 010 KB).

Upvotes: 1

Related Questions