couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Hewitt <>
Subject Re: MochiWeb, acceptor pool sizes and handoffs
Date Wed, 14 Sep 2011 15:49:18 GMT
Thanks all, makes much more sense now!


On 14 Sep 2011, at 15:57, Adam Kocoloski wrote:

> Heh, you all beat me to it. Sean's on the right track -- the idea behind the pool is
to reduce the time required to accept() a new connection and minimize the chances that you
exhaust the kernel's listen queue (e.g., somaxconn) in cases of really bursty traffic.
> On Wednesday, September 14, 2011 at 10:54 AM, Adam Kocoloski wrote:
>> Hi Martin, iirc the default acceptor pool size is 16.
>> Here's how the pool works: those 16 processes are all competing to accept() a new
connection on the socket. When one of them succeeds it executes CouchDB's HTTP code and is
replaced by a newly-spawned process in the pool. The process now executing CouchDB code continues
to loop, handling requests on the connection until it's closed. At that point the process
shuts down -- it never returns to the pool.
>> NB: all of this applies to CouchDB 1.1.0+. CouchDB 1.0.x used an older version of
Mochiweb which did not have an pool of acceptor processes at all. Best,
>> Adam
>> On Wednesday, September 14, 2011 at 6:55 AM, Martin Hewitt wrote:
>>> Hi all,
>>> We've got a dedicated CouchDB server and I'm looking at ways we can improve its
performance. One I've hit on is increasing the size of the MochiWeb acceptor pool, but a background
thought occurred to me: does CouchDB hold open MochiWeb acceptor threads whilst it runs whatever
process (i.e. a view rebuild if a view's requested) is needed or does it hand-off to another
thread, returning the MochiWeb thread to the pool? Is the MochiWeb thread released if the
client closes the HTTP connection?
>>> We're currently using HEAD requests to keep view rebuilds ticking over, which
works fine, and, as far as I can tell, releases a MochiWeb thread right away, as soon as the
request is completed, but I'm just thinking about circumstances under which the thread pool
might become saturated.
>>> An aside: what's the default size of the thread pool?
>>> Thanks,
>>> Martin 

View raw message