incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <>
Subject Re: MochiWeb, acceptor pool sizes and handoffs
Date Wed, 14 Sep 2011 14:51:56 GMT
Oddly enough I recently read something about this by an off chance visit to
the MochiWeb board.

Sounds like what Paul said is correct. The request comes in and is passed to
a process in the pool. A new one is created to take it's place and when the
response is sent back the original process just dies in the normal Erlang

So I guess the pool size is just to help with bursts of traffic to cut down
on process startup. Which I have no idea how minor or not that is.

On Wed, Sep 14, 2011 at 10:39 AM, Paul Davis <>wrote:

> 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 saturated.
> >
> > An aside: what's the default size of the thread pool?
> >
> > Thanks,
> >
> > Martin

“The limits of language are the limits of one's world. “ - Ludwig von

"Water is fluid, soft and yielding. But water will wear away rock, which is
rigid and cannot yield. As a rule, whatever is fluid, soft and yielding will
overcome whatever is rigid and hard. This is another paradox: what is soft
is strong." - Lao-Tzu

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message