couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: MochiWeb, acceptor pool sizes and handoffs
Date Wed, 14 Sep 2011 14:39:41 GMT
Couple points in no particular order:

Calling it a thread pool is a bit misleading. Erlang processes are
much more lightweight than a thread. Also, I'm fairly certain that
this isn't even a pool. I'm pretty sure that processes are never
returned to it. Once a client disconnects the process ends. Also, once
a client connects and the process goes to handle it, a new process is
added to the pool. I haven't done too much tuning personally on the
size, so I'm not sure how much performance boost to expect from making
it bigger.

Given that, no a GET request to a view will hold the process until the
view update finishes and returns. And technically a HEAD should have
the same behavior. My guess is that you're just seeing the processes
being spawned and added to the pool if you're logging such things.

I think the default size is 16 but that's half guess because I haven't
looked at the code lately.

On Wed, Sep 14, 2011 at 10: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
> An aside: what's the default size of the thread pool?
> Thanks,
> Martin

View raw message