httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: Apache 0.7: too many processes
Date Mon, 26 Jun 1995 09:45:35 GMT

> 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.

This was discussed before any 0.7 code was written. After some input from
serveral people, including Rob McCool (Netsite takes the same approach),
it was decided that, forking processes to meet demand wasn't a good idea.
I was worried that a fix number of processes (dozens of them) would be
a bottleneck.

The sysadmin at Cardiff setup a 2nd server the other week, and ran 0.6.x
on it because he didn't want to "waste" RAM on apache processes which were
sitting around doing nothing. I explained how the forking/preforking versions
compared, and he agreed that (in theory at least), that having "too many"
0.7.x apaches would be less overhead than 0.6.x

Ideas on how to fork new processes to meet additional demand were discussed,
but none made any real sense. To fork to meet demand seems to need a
centralised "accept" or child<->parent communication, which we have 
made great efforts to avoid so far.

If there are any low overhead solutions to this problem, lets hear them.

View raw message