Re: [hybi] hum #3: Message

[Scott Ferguson <[e-mail]>]

Willy Tarreau wrote:
> On Fri, Aug 06, 2010 at 06:46:19PM -0700, Scott Ferguson wrote:
>   
>> Any of 16/64, or 8/16/64 or 8/32/64 would be fine, but 8/64 is a poor 
>> choice for chunking because 256 bytes is too small to be a reasonable 
>> chunk, and 64 bits is a waste. Suppose you're using a 8k buffer. With 
>> the 8-bit length, you need 32 chunks just to send the buffer. With the 
>> 64-bit length, you're wasting 6 bytes. With those as the only options, 
>> you're stuck between two bad choices.
>>     
>
> You're wasting 6 bytes per 8kB, so less than 0.07%. It's even less than
> the single byte you waste for 256 bytes (0.4%). The worst case is when
> you send 2048 bytes. You waste exactly 8 bytes by either 8 8-bit chunks
> or one 64-bit chunk, which in both cases represent 0.39%. But this is
> still equal to the minimum 8-bit chunk overhead. So in fact if we wanted
> to always have a lower overhead, we'd have to completely remove 8-bit
> chunks, but I don't think that would be a good idea.
>   

Let's look at the full comparison between 8/64 and 16/64. The values in 
the table below are frame overhead for various message/chunk sizes 
(8-bit length is a 2 byte frame, 16-bit length is 3 bytes, and 64-bit 
length is 9 bytes):

          8/64      16/64     64
  --------------------------------
  32      6.3%      9.3%     28.1%
  128     1.6%      2.3%      7.0%  
  256     3.5%      1.2%      3.5%
  512     1.8%      0.6%      1.8%
  2048    0.4%      0.1%      0.4%
  8192    0.1%      0.04%     0.1%

(Note that 8/64 only beats 16/64 in the upper left.)

Three ways of looking at the table:

  a) optimal length given a priori knowledge of the message size
  b) practical length given dynamic content. (When it's not known if a 
32 byte echo/print/write is the full message or the first part of a 
bigger message.)
  c) chunking

a) For optimal, it all depends on the message-length distribution. When 
messages are tweets, 8/64 is better (1.6% vs 2.3%). When messages are 
between 256 and 64k, 16/64 is better (0.6% vs 1.8% for a 512-byte 
message, and 0.15% vs 0.44% for the 2048-byte chunk example).

b) For dynamic content, the upper-right table values are the problem. 
The 28.1% and 7.0% are more than they need to be. Even so, it's still 
probably not worth shifting the content. So the optimal 8/64 becomes a 
practical 64-bit fixed length because it's not worth the effort to 
repack the data.

c) Chunks would be between 512 and 64k, depending on the 
implementation's buffer size. In that range, 16/64 is always superior. 
It's only the final chunk that might benefit from an 8-bit length.

Even though 16/64 is a better choice overall (given dynamic-content 
pragmatic issues, chunking needs, and uncertainty about the real-world 
message-length distribution), 8/64 is workable. The 28% and 7% overheads 
in the upper right are inelegant, and the extra chunking overhead is 
less efficient, but it's workable.

-- Scott

> So all in all, I think that the 64-bit csize always offers lower overhead
> than the 8-bit ones so it will always be more efficient above 2 kB than
> anything sent in 8-bit blocks, and the overhead is still small.
>
> Regards,
> Willy
>
>
>
>
>