> Clearly you would need child -> parent communication, but not necessarily
> the reverse. Why is that a bad thing?
it's not a bad thing, just something that hasn't been needed so far,
and thus makes the model simpler.
If we move to a new logging system based on children offloading info as
and when they find it, there may well be some child->parent communication
if it is decided that the parent is a good place to do the logging.
But surely if a current user of Apache or 1.3 is worried about the wastage
you mentioned, then won't they already have hit meltdown point when it forks
unlimited numbers of children to talk to multiple mozillas each fetching
4 inlines at a time.
In the example David gave, of a 5 process apache being swamped by
a couple of Mozilla users, I'd guess that a forking server would
be unable to fork processes when needed, and the connections would just
be lost.
0.7 will have a fixed overhead and there's no way to exceed it. The
webmaster will configure Apache and if necessary swapspace to match
the allowable max concurrent requests.
I'd be interested to see any stats that have been collected which
map the number of children required to the daily load or hourly peeks.
I had 80 children running at Cardiff. Now there are 40, and the
responses are always instant... I suspect lots of people will overestimate
how many processes they actually need... 40 children on a 100k hits/day
server with lots of CGI seems to be very comfortable.
> The server needs a fast response to increasing load, with a slower falloff
> when the load drops. The latter can be done as a first-order Poisson process
> with the children killing themselves after a random (but constant mean)
> interval.
It's possible to SIGHUP at different times of the day, to reconfigure
the number of children.. have more during peek hours, less overnight.
It'd be nice (and not impossible) to use another signal to increase the
number of children, without killing running children.
> The parent needs to know how often no child is 'accepting' on the socket
> in order to determine when more children are needed. Maybe it could try
> selecting on the socket itself, to determine if the queue of incoming
> connections stays non-empty.
there's also the chance that if you wait another millisecond, a dozen
children will be ready to accept again... there's a danger of overkill,
spawning so many processes that they make it impossible for each other
to do any work. This was one of the big pluses for a fixed process number.
> Or alternatively, the children could send
> it messages each time the call and return from accept().
> The latter could also be used as keep-alives for the parent to notice
> dead children, and allow it to bury them. You should be doing this sort
> of communication anyway, for the hostname cache.
At the moment the hostname cache isn't being used. We've yet to see if
it is better to leave that to a logging process and/or to the CGI scripts...
I bet 99% of CGI scripts don't even look at the client's hostname.
> Of course, on those machines where you are forced to put a (shared-memory)
> lock around accept(), you get low-overhead child <-> parent IPC for free.
rob
--
http://nqcd.lanl.gov/~hartill/