incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <adam.kocolo...@gmail.com>
Subject Re: MochiWeb, acceptor pool sizes and handoffs
Date Wed, 14 Sep 2011 14:57:24 GMT
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 



Mime
View raw message