You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Robinson <dr...@ast.cam.ac.uk> on 1995/06/26 17:29:00 UTC

Apache 0.7: too many processes

I've had a quick look at apache 0.7, and it sees to suffer from a major
design flaw, namely that it always starts up a fixed number of processes.

This would be a pretty major disincentive for a low-use site to run apache.
Running tens of daemons is very wasteful on swap space and kernel resources,
and will put off sys admins. But a 0.7 server with a small number of daemons
(5, say) would probably provide an inferior service to a 0.6 server.
All it would take is one netscape user to access a page with a few inline
images, and your site is saturated.

So I would suggest that is is essential that apache adapt the number of
daemons to the varying connection load.

 David.

Re: Apache 0.7: too many processes

Posted by Rob McCool <ro...@netscape.com>.
/*
 * "Re: Apache 0.7: too many processes" by rst@ai.mit.edu (Robert S. Thau)
 *    written Mon, 26 Jun 95 20:42:43 EDT
 * 
 **    One suggestion has been (and I think this is what NCSA 1.4 and
 ** Netsite do) is to start with "x" servers, and when all servers are
 ** being used and a new request comes in fork a short-lived
 ** one-request-service child, up to "y" possible children total.
 * Hmmm... I believe NCSA 1.4 does this, but I don't think Netsite
 * does.
 */

That's correct. Netsite also implements the lockf() around accept()
that Cliff's friend suggested after we made a stink about this with
Sun last fall.

--Rob

Re: Apache 0.7: too many processes

Posted by Brian Behlendorf <br...@organic.com>.
On Mon, 26 Jun 1995, David Robinson wrote:
> So I would suggest that is is essential that apache adapt the number of
> daemons to the varying connection load.

Then what's the difference between that and 0.6.5?

One suggestion has been (and I think this is what NCSA 1.4 and Netsite do) is
to start with "x" servers, and when all servers are being used and a new
request comes in fork a short-lived one-request-service child, up to "y"
possible children total.  I don't know if that's possible without serializing
requests though.... what's a *real* solution is to distinguish between
short-lived responses and long-lived responses, so that 10 people downloading
a 6 meg MPEG movie from your site over a 14.4 modem don't swamp your 
10-child server.  Any ideas?

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/