[Mongrel] Mongrel woes fixed

Zed A. Shaw zedshaw at zedshaw.com
Wed Oct 4 19:31:10 EDT 2006

On Tue, 3 Oct 2006 16:51:55 -0700
"Jeremy Kemper" <jeremy at bitsweat.net> wrote:

> On 10/3/06, Jacob Atzen <jacob at jacobatzen.dk> wrote:
> >
> > I'm still not sure why I'm the only one seeing these problems. Maybe
> > others are seing them too and just not being aware of them. Maybe they
> > only show up when the Mongrels gets severely loaded. Maybe I'm simply
> > the only one butchering poor Mongrels for fun in my spare-time? ;-)
> I see the same behavior with a handler that does some slow, blocking IO
> (resolving symlinks on heavily loaded NFS servers). I worked around it by
> using more Mongrels instead of more worker threads and by backgrounding one
> long-running task which could safely send an HTTP response before
> completing.
> It'd be cool if Mongrel forked itself (up to a max # of processes) to
> alleviate the issues that arise with Rails  handler locking and with
> blocking IO due to Ruby's green threads. Mongrel cluster could work but it
> feels like overkill when forking would do the job with zero config (minus
> Win32).

It actually wouldn't be hard to write a simple HttpHandler that was inserted before rails which just called fork to continue the request, but I think it'd require a shift in how the response is processed in Mongrel.

The problem with forking servers is they are slow and they end up having the same problems we're seeing with threads just with processes (which eat up ass loads more ram than a dead thread).  I'm really more interested in something that's in-between full on 50M forked processes for each request and nasty ruby threading causing problems.

Another thought might be to have such a forking handler for Mongrel, but make it selective so that it only forked the troublesome requests.

Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

More information about the Mongrel-users mailing list