Re: [hybi] hum #3: Message

[Roberto Peon <[e-mail]>]

If we're going over TCP/IP, you may as well think about the overhead for the
TCP/IP headers.
It ends up coming down to transaction rate as much as anything else.
-=R

On Sat, Aug 7, 2010 at 12:21 PM, Scott Ferguson <[e-mail]> wrote:

> 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
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>