[erlang-questions] Curiosity about MochiWeb (no questions this time)

[Alessandro Sivieri]

Hi all,

I was looking to an appmon instance launched from a node with MochiWeb
active, and I saw a few processes linked to the _web process, so I was
wondering if MochiWeb generates something like a pool of processes for
client requests, which may explain why there were all those processes...

--
Sivieri Alessandro
alessandr...@gmail.com
http://www.chimera-bellerofonte.eu/
http://www.poul.org/

[AJ Heller]

Mochiweb spawns a pool of short-lived processes (from the
`mochiweb_acceptor` module), and re-spawns new acceptor processes when
each finishes/times-out. The default settings are: 16 processes are
alive at a time, and they timeout after 2 seconds.

I did some analysis of the Mochiweb code a while back. There's a
diagram at the bottom of the page that lays out the program flow.
http://drfloob.com/wiki/erlang_mochiweb_walkthrough.html

--aj

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questio...@erlang.org

[Pablo Platt]

I'm using Mochiweb for long-polling.
Each request can take 60 seconds.
I didn't change the default settings so how come I didn't have issues with the 2
seconds limit?
Does it means that I won't be able to have more than 16 concurrent long-polling
requests?

________________________________
From: AJ Heller <a...@drfloob.com>
To: Alessandro Sivieri <alessandr...@gmail.com>
Cc: Erlang Questions <erlang-q...@erlang.org>
Sent: Thu, November 4, 2010 11:17:05 PM
Subject: Re: [erlang-questions] Curiosity about MochiWeb (no questions this
time)

[Bob Ippolito]

No, the behavior described is only relevant to how accepting sockets
works. This does not limit the number of active requests you have and
it is not at all relevant to long polling.

It exists for the sole purpose of trying to minimize variance for how
long accept will block by doing it from a parallel pool of processes.
Once the socket has been accepted the process starts handling the
request and a new acceptor process is created to take its place. You
have 16+N processes looking at sockets, 16 of them blocking on accept
and N of them working on active requests. The timeout of 2 seconds is
just a sledgehammer to make sure that the whole accept pool don't get
tied up waiting on some series of problematic sockets.

This whole part of the system might be a little pessimistic but the
point of this work was to try and hunt down some boogeyman in our
stack that would make some very small percentage of requests take
several seconds instead of several msec. It didn't ultimately fix the
whole problem but we did notice lower variance so we kept it.