httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject FastCGI Proxy Branch Design Questions
Date Sun, 25 Dec 2005 16:06:03 GMT
So I've been taking a look at the new work Paul's been doing on the
fcgi-proxy-dev branch, and it looks really cool, but I've got some
questions on its direction.  What's there now is the beginnings of
functionality to let you use mod_proxy to send requests for particular
parts of the URL space to a back end FastCGI process.  This is
fantastic, but it's only part of the equation.  We also need some
mechanism for actually starting and managing the FastCGi processes.

One of the things people like about lighttpd is the way it can start
up N back end processes, then if one of them dies for some reason
it'll simply restart it for you.  In order to do this kind of thing it
seems like we'll need something keeping track of what FastCGI
processes have been started, which are currently in use, and other
such bookkeeping information.

Now since we need to be able to run in multiprocess configurations,
that means either the bookkeeping data needs to be kept in shared
memory, or all this info needs to be managed by a separate child
process (similar to the mod_cgid stuff I imagine).  The separate child
process plan seems easier to implement correctly, but it also means
that the process of grabbing hold of a FastCGI process would reqiure
some sort of IPC, sending requests over a socket or something, which
is potentially slow.

I suppose this could be made less of an issue by introducing some sort
of scheme where a httpd process can hold on to a back end FastCGI
process as long as it wants to use it, which is fine as long as the
manager child can tell when the httpd process has died or otherwise
gone to never never land so it can either regain control of the
FastCGI process or kill it and start another.

Personally, I'm leaning towards the manager child process way of doing
things just for ease of implementation, since we can always go with
something else later if it proves necessary.

Anyway, just some ideas that had been kicking around in the back of my
mind.  Has anyone else put any work this part of the FastCGI stuff?

-garrett

Mime
View raw message