httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@ast.cam.ac.uk (David Robinson)
Subject Re: Possible work this weekend...
Date Thu, 13 Jul 1995 15:51:00 GMT
>From: rst@ai.mit.edu (Robert S. Thau)
>Date: Fri, 7 Jul 95 13:55:16 EDT

>3) A new strategy for managing the number of extant child processes:
>
>   This would involve putting up a scoreboard for the child server
>   processes, indicating their state.  This would be a file in which
>   each child server has a few words to indicate its pid, and whether
>   it is waiting for a request.  This allows us to then do the
>   following:
>
>   The root server periodically checks to see how many child servers
>   are waiting for a request.  If there are fewer than some set
>   "MinFree" value, it forks off a *single* new child, and then goes
>   to sleep for a little while.  Conversely, when a child is about to
>   wait for a new request, it checks the numbers of its fellow
>   children which are already waiting.  If that's greater than
>   "MaxFree", it dies off.  The aim here is to automatically spawn off
>   new servers if all of them are taken up with slow clients, without
>   ever reverting to full forking mode, and without keeping large
>   numbers of server processes idle when the server is just not busy
>   (which is bad, as they tend to get swapped out).
>
>   I figure we want at most one new child per second, to keep it from
>   going nuts in response to some transient load spike; I was going to
>   try MinFree and MaxFree of 5 and 20 respectively.

Earlier I suggested a slightly different scheme; (if anyone commented on it,
then I didn't receive their messages)

  Create a new process if there are no children waiting to accept.
  (i.e. MinFree = 1), up to a maximum rate of cmax.
  A process dies after a (perhaps random) time tmax.

I originally suggested that tmax scale with the mean connection time.

The number of processes is limited to cmax*tmax.

It has the advantage that the server should always fall back to the quiescent
state of one parent and one child when no connections are received.
The children have a finite life as a check against resouce lossage; although
shambhala looks to be better than apache in that respect.

The main problem with any such scheme is that it _requires_ IPC.
Hence, if something like this is implemented, it should be designed around
the IPC rather than vice versa; once we have IPC there are lots of other
useful things that can be done. (Alternative accept locking, DNS caching,
logging etc.)

  David.

Mime
View raw message