here is an excerpt from httpd.h:
/*
 * (Unix, OS/2 only)
 * Interval, in microseconds, between scoreboard maintenance.  During
 * each scoreboard maintenance cycle the parent decides if it needs to
 * spawn a new child (to meet MinSpareServers requirements), or kill off
 * a child (to meet MaxSpareServers requirements).  It will only spawn or
 * kill one child per cycle.  Setting this too low will chew cpu.  The
 * default is probably sufficient for everyone.  But some people may want
 * to raise this on servers which aren't dedicated to httpd and where they
 * don't like the httpd waking up each second to see what's going on.
 */
#ifndef SCOREBOARD_MAINTENANCE_INTERVAL
#define SCOREBOARD_MAINTENANCE_INTERVAL 1000000
#endif

and the code from http_main.c:

    if (idle_count > ap_daemons_max_free) { #retrieved indirectly from MaxSpareServers
        /* kill off one child... we use SIGUSR1 because that'll cause it to
         * shut down gracefully, in case it happened to pick up a request
         * while we were counting
         */
        kill(ap_scoreboard_image->parent[to_kill].pid, SIGUSR1);
        idle_spawn_rate = 1;
    }

Perrin Harkins wrote:

> On Wed, 17 Jan 2001, Sam Horrocks wrote:
> > If in both the MRU/LRU case there were exactly 10 interpreters busy at
> > all times, then you're right it wouldn't matter.  But don't confuse
> > the issues - 10 concurrent requests do *not* necessarily require 10
> > concurrent interpreters.  The MRU has an affect on the way a stream of 10
> > concurrent requests are handled, and MRU results in those same requests
> > being handled by fewer interpreters.
>
> On a side note, I'm curious about is how Apache decides that child
> processes are unused and can be killed off.  The spawning of new processes
> is pretty agressive on a busy server, but if the server reaches a steady
> state and some processes aren't needed they should be killed off.  Maybe
> no one has bothered to make that part very efficient since in normal
> circusmtances most users would prefer to have extra processes waiting
> around than not have enough to handle a surge and have to spawn a whole
> bunch.
>
> - Perrin

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/


Reply via email to