httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Possible work this weekend...
Date Fri, 07 Jul 1995 13:55:16 GMT
I'm planning to put another solid day or two into Shambhala this
weekend.  Aside from fixing any open bugs which may come up, I've got
three things I'm thinking about; the last two at least have been on my
TODO list for a while, but some of them do involve (minor)
incompatible changes to the API.

If I get all this done (and perhaps even if I don't), I'm strongly
considering a feature freeze on the server core and the current module
set until the first public release after that (new modules would be
fine).  If anyone thinks there's something wrong with the plan, please
let me know...

1) Attempt the change in handling of timeouts and client aborts which
   I discussed earlier this week --- don't immediately longjmp() out
   of module code back to http_main(); just put the connection in an
   aborted state.  This means that whatever code that the module may
   need to clean up its work in progress will still run.  (This should
   make integration with the run time systems for languages other than
   C a little easier, and give module writers generally a somewhat
   less threatening environment).

2) Give modules a one-time initialization function, to be called once
   at start time (or when the module is first loaded, if it's loaded
   at run-time by something like mod_dld).  Allow them to request new
   AllowOverrides and Options bits at this time (so that a SetEnv
   module could could add AllowOverride Environment, to govern the
   placement of SetEnv directives in .htaccess files).  I might want
   to change the command tables as well to make the interface to this
   facility little more graceful; right now, it's basically set up to
   be convenient only if the bits in the "where-allowed" bitmask are
   known at compile time.

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.

I can't promise I'll get to all these, and I certainly can't promise
they'll all work, but that's the plan.  Any comments?  [I probably
won't start till Saturday noon, and whatever looks like the worst idea
can probably be put off...].

rst

Mime
View raw message