tuning riak for 100s of concurrent connections
russell.brown at me.com
Sat Feb 26 09:28:59 EST 2011
On 25 Feb 2011, at 18:31, Wilson MacGyver wrote:
> Another possibility that comes to mind to avoid the setup cost is to
> do connection pool
> of some sorts.
> Does any of the riak client lib supports connection pooling?
Late to this party, sorry.
The Java REST client makes use of Apache HttpClient so connection pooling is available (and you can set TCP_NODELAY using the HttpConnectionParams of the HttpClient.)
The Java protobufs client creates a connection per thread that uses the client , it will reuse the connection (if it is not idle for a second or more.) so you can create *n* threads and share (either) RiakClient implementation between them (I haven't tested this with the protobufs client yet, so caveat emptor.)
> On Fri, Feb 25, 2011 at 1:25 PM, Sean Cribbs <sean at basho.com> wrote:
>> Now you're talking about tweaking kernel-level settings -- something well outside my expertise (although TCP slow-start comes to mind). That said, it's kind of hard not to use TCP if you want a reliable connection, warts and all.
>> Sean Cribbs <sean at basho.com>
>> Developer Advocate
>> Basho Technologies, Inc.
>> On Feb 25, 2011, at 1:06 PM, Wilson MacGyver wrote:
>>> any advise to solve this?
>>> On Fri, Feb 25, 2011 at 1:05 PM, Sean Cribbs <sean at basho.com> wrote:
>>>> Yes, the majority of the cost is probably in TCP setup. That pain is happening at the TCP stack level, not in Erlang. It's actually really cheap and easy to spawn a new process in Erlang, so there's no reason to have "standby workers", especially when they don't need to maintain state between requests.
> Omnem crede diem tibi diluxisse supremum.
> riak-users mailing list
> riak-users at lists.basho.com
More information about the riak-users