httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@hyperreal.org>
Subject Re: Apache 2 mutiple pools feature request
Date Wed, 03 Mar 1999 17:14:42 GMT
> > In fact we're really going to want something equivalent to a wire protocol
> > approximating the Apache API anyways, for robustness, when we go
> > multithreaded.  Apache is legendary for its stability, which owes no small
> > debt to the multiprocess model, the fact that bad code only kills its own
> > single connection.  When we go multithreaded, we run the risk of someone's
> > bad module code (or worse, someone's bad perl code when used with
> > mod_perl, or bad PHP plug-in code...) bringing down the whole server,
> > clearly an untenable solution for ISPs or most anyone else.  Having N
> > processes with M threads only reduces the problem by 1/N, and since we're
> > going multithreaded to try and keep N as close as we can to 1....
> 
> I think as long as N>1 but still closer to 1 than in the pure
> multi-process model, we still retain the stability while gaining some of
> the benefits of the threaded model, assuming the crashing problem is
> occasional.

I guess I'm just not of the opinion that the crashing problem will be
occasional, *when* third party modules are in use.  I am all set to
believe we can make the standard module set robust enough to run dangerous
like this - but I think it'd be really nice to tell module authors they
have a separate process space that's all their own to mess up.

> How would this relay protocol work on WIN32?  At least on Win95/98 having
> two processes running trying to speak to each other is nowhere near as
> efficient as loading a DLL into the main process.

Granted.  This is worth asking the Java folks, at least asking how it's
impacted them on NT.  Win98/95 I could care less about performance, the
main reason to run a web server there is for development/testing.  So it
should work OK but latencies can be much higher and still be acceptable.

Perhaps the most flexible thing to do is provide an API which works for
either the single-process space and the multi-process space.  E.g.

Apache2 multithread daemon -API- module

Apache2 multithread daemon -TCP- daemonprocess -API- module

That way people can decide whether they trust "module" enough to be in the
same process space, or outside of it.

> I also don't quite understand where the line between needing a backend
> server vs. being a true module is drawn.  For example, would mod_status
> now have to be rewritten as a standalone server?  What about mod_proxy?

No, I'd leave those in the core.

> mod_dav?  mod_cgi?  The last two would definitely benefit from the
> different-user ability that this would bring.

mod_cgi already has suexec, and since mod_cgi is just another relay
module in essence, there's not much need to split it out.

mod_dav, I don't know.  It can probably use something like suexec to
perform user-specific functions when necessary.  

I guess the place I draw the line is programmability.  If the module is an
interpreter for a programming language, it probably makes sense to give it
its own process space.  So maybe what I'm advocating is just a distinct
API for dynamic content engines - and that certainly doesn't need all the
power of the Apache API.

> The other issue is that this is radically different from how all the other
> servers work.  We are currently working on an ISAPI, NSAPI, WSAPI, Apache
> API abstraction layer which will move all server API related code into a
> thin layer outside of PHP and thus making PHP a generic web server module
> that can be used with any server.  Adding code to have PHP run as a
> standalone daemon probably wouldn't be too hard, but architecturally it
> would be a bit of a stretch.

Well it sounds like the interface that "thin layer" provides is an
excellent candidate for a wire protocol.  :)

More seriously... it sounds like it would be nothing but a benefit to PHP,
because then PHP would be controlling things like shared memory,
its own process management, protecting itself from other server modules,
etc.  And then you'd get the per-UID idea for "free" on all servers;
otherwise you'd have to make this same separate-pools suggestion to all
the other server developers too.

> If this IPC protocol thing does become a reality, I would probably just
> provide it as an option for large ISP's who need the security benefits
> it brings.  For large dedicated single-user sites, I doubt the IPC
> approach can come anywhere close to the speed the true module architecture
> brings so I think this model is likely to always be the primary approach.

The main performance slowdown I see is the extra I/O involved in copying
the response from the backend daemon, out to the HTTP connection.  I don't
have an easy answer for that; ISTR that we don't really want to give
modules direct access to the socket anymore anyways, due to HTTP/1.1
issues.


So let me craft the discussion like this - is there an API we could write,
for dynamic content engines specifically (forget about cool stuff like
being able to create your own mod_status output just for a sec), that
could optionally and efficiently exist on the other side of a TCP
connection from the main HTTP server.  I think we can do that... and if
you work on the API, I bet others will figure out the wire protocol side
of things....

	Brian




Mime
View raw message