Re: [hybi] hum #3: Message

[Scott Ferguson <[e-mail]>]

Willy Tarreau wrote:
> On Sat, Aug 07, 2010 at 12:38:11PM -0700, Roberto Peon wrote:
>   
>> 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
>>     

That's a good point. It's also an argument for a fixed 64-bit length.

>
> Yes, but if/when we add multiplexing, it might be nice to be able to push
> as many transactions as possible in a single TCP segment.
>   

True, but you need a high message rate, even with multiplexing, to make 
it worth delaying. (I can't estimate how often that will happen. Maybe 
someone has a good feel for this?)

> Scott, in my opinion, what is important is not to compare overheads together
> but efficiency (payload/total), which is what really matters. Indeed, halving
> the overhead when it's already not noticeable won't save much bandwidth.
> However if we can keep it low for small packets, it helps :
>
>
>             8/64      16/64     64          8/64 vs 16/64
>      --------------------------------
>      16     88.9%     84.2%     64.0%          +5.6%
>      20     90.9%     87.0%     69.0%          +4.5%
>      32     94.1%     91.4%     78.0%          +3.0%
>   

Yes. That's a good way of looking at the data.

> Now we see that above 512 bytes, we're fighting in the same yard with every
> model. However, I think that it's interesting to note that below 128, 8/64
> has a significant advantage (and 64 alone is a total waste).
>   

It's a space vs complexity trade-off.

Is it worth the extra implementation complexity of the 256-byte boundary 
to save 5% space? For me, no. I would happily pay that 5% to keep my 
code simple.

> I have intentionally added the 255-bytes message so see the maximal
> theorical efficiency on 8-bit. In fact it will often be between 0.5% and
> 2% more efficient than the 16-bit model for tweets. Also, in my opinion,
> we should theorically plan to send messages up to 510 bytes as 2 chunks
> of 255, which finally improves efficiency to 98.5 for the 256-bytes message
> (and up 99.2 for 512-bytes). This finally results in -0.3% for 8 vs 16
> instead of -2.2%.
>
> So in fact with 8 bit we could get savings of up to a few percent compared
> to 16-bit on very short messages, and losses of at most 1.1% (511-bytes).
> That's why I think it should still get an advantage, eventhough I admit
> both tie on medium to large messages.
>   

This is all true, but I'd still prefer the savings in code complexity 
because the difference in space is close enough, imo.

-- Scott
> Regards,
> Willy
>
>
>
>
>