memcached and streaming

[dormando]

>>
>> We should realise that this is a serious performance killer for
>> streaming.  For instance, C::M::F has multi-update commands that are
>> capable to bundle several requests into one network packet.  However
>> replies are always sent _one at a time_.  I.e. tons of packets with
>> single 'STORED' etc. (>40 bytes header and 6 bytes of data---not the
>> best ratio).  Not to say the the greater number of packets means a
>> huge increase of latency in a congested network.
>>
>> memcached should have in its TODO "Disable TCP_NODELAY and enable
>> TCP_CORK/TCP_NOPUSH for streaming".  The server may tell if the
> 
> Just a quick note: the code to set/clear TCP_NOPUSH was here before iov
> work was merged from facebook at r320 (i.e. in 1.1.* branch).
> 
> Maxim Dounin

Yeah; I want to rewrite the way the iov code works... It's not flexible
enough, relies on mallocing lists _per conn structure_ instead of a
linked list, and in certain conditions uses too many packets.

Under an mget response the iov stuff works great. Otherwise it's
probably still fine since most people don't stream changes. It'd be nice
to handle all cases better, so I can remove things like the text
protocol CAS hack, and for the few folks who stream changes around.

-Dormando