tuning riak for 100s of concurrent connections

Les Mikesell lesmikesell at gmail.com
Fri Feb 25 12:36:35 EST 2011


But it sounds like the thing causing the latency - and I can't imagine a 
scenario where you would want additional latency.   It is going to add a 
delay any time you need to send a small packet with an unacknowledged 
packet already outstanding and you aren't closing the socket.  If that's 
a common scenario (as it would be with connection caching) it should be 
disabled.  It only helps when an app does small writes on an output 
stream and you want them transparently buffered into large packets 
anyway. Not sure if that applies to riak or if it does it's own buffer 
chunking.


On 2/25/2011 11:00 AM, Sean Cribbs wrote:
> I wasn't commenting that one should disable it, just that the option is there. I think it depends on your operational needs, namely the latency between the clients and Riak.
>
> Sean Cribbs<sean at basho.com>
> Developer Advocate
> Basho Technologies, Inc.
> http://basho.com/
>
> On Feb 25, 2011, at 11:52 AM, Les Mikesell wrote:
>
>> On 2/25/2011 10:37 AM, Sean Cribbs wrote:
>>> You can disable Nagle on the riak side (at least on 0.14 and later). Put this in the riak_core section of app.config:
>>>
>>> {disable_http_nagle, true}
>>
>> Shouldn't that be the default if clients are able to cache connections?  You'll normally get the delay if your protocol isn't a strict serial handshake and you need to send a small packet with data already outstanding (like at the end of a request where the socket isn't being closed).
>>
>> --
>>   Les Mikesell
>>    lesmikesell at gmail.com
>>
>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>





More information about the riak-users mailing list