httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Apache 2 mutiple pools feature request
Date Mon, 01 Mar 1999 09:15:56 GMT

For what it's worth, the jserv developers have the same problem.  Of
course, they have an advantage, in that their model is to run a backend
daemon for java requests, and it's not difficult to configure more than
one daemon running as different UID's.  

Formalizing this as something that Apache does makes some sense to me;
e.g., having a standard interface to back-end daemons for launching (as
root, setting to a particular UID) / restarting / killing, distributing
requests, etc.  Maybe even a standard back-end protocol, like what jserv
uses today.

I'm sure the Perl folks would prefer to write their daemon in
multithreaded Perl, and of course the jserv developers are already using a
JVM for this, so I don't think we'd need to go so far as create daemon
stub code or anything.  This would be a real boon to those people being
asked to run PHP *and* jserv *and* mod_perl on their systems (like me at
taz :) - instead of a mod_perl, mod_php and mod_jserv, we just have
mod_relay which relays a compiled version of the request (or subrequest)
to the backend daemon based on request parameters, and awaits the

Yes, you have the IPC overhead, but on modern architectures that's less
significant.  Or so I've been led to believe - the benchmarks out of
mod_jserv are pretty nice.

This is still relevant when we go multithreaded in 2.0, too.  It'll be
nice to insulate the raw HTTP engine from dangerous code in dynamic
content engines which may be less robust.

Rasmus, what do you think?  I bet you could get started by writing
something using the jserv protocol already :)  


On Mon, 1 Mar 1999, Rasmus Lerdorf wrote:
> I have brought this up before.  But since development is fast and furious
> right now, I thought I would restate it.
> Many sites are running multiple httpd pools as different user id's these
> days.  Many because I advised them to do so because it is the best way to
> run an Apache/PHP or Apache/mod_perl server where you want to make sure
> that different users writing PHP or mod_perl scripts can not step all over
> each other.  Running PHP or Perl as a cgi under suExec is of course one
> way, but you lose all the performance the module version.  PHP also has a
> safe_mode feature, but it can be restrictive and confusing and I wouldn't
> bet the farm on it.  This is one area where Alex Belits' fhttpd server is
> very nice (
> It would be nice if this could be specified from a single httpd.conf file
> as opposed to forcing people to maintain multiple configuration files.
> Something like:
> User nobody
> MinSpareServers 10
> MaxSpareServers 20
> StartServers 10
> ThreadsPerServer 5
> MaxClients 256
> <Pool web1>
> User web1
> MinSpareServers 1
> MaxSpareServers 2
> StartServers 1
> ThreadsPerServer 100
> </Pool>
> <Pool web2>
> User web2
> </Pool>
> <VirtualHost My.Host>
> ServerName My.Host
> Pool web1
> </VirtualHost>
> Or I suppose you can just specify different user id's in the VirtualHost
> blocks and figure it out from there, but it might be cleaner to have
> distinct pool definition blocks.
> -Rasmus

View raw message