Re: [fwd] How to SysAdmin Apache FCGI ?

Tom Neff (tneff@ns1.bloomberg.com)
Wed, 19 Mar 1997 11:31:13 -0500

Message-Id: <3.0.32.19970319110508.00f886d0@mothra.bloomberg.com>
Date: Wed, 19 Mar 1997 11:31:13 -0500
To: fastcgi-developers@OpenMarket.com
From: Tom Neff <tneff@ns1.bloomberg.com>
Subject: Re: [fwd] How to SysAdmin Apache FCGI ?

At 08:23 AM 3/18/97 -0500, Rujith de Silva wrote:
>I usually run the FCGI processes so that they automatically restart
>themselves after handling some number of requests.  This is nearly
>good enough to handle reloading a config file, etc.

If the FCGI process is really frequently "hit," this is almost the same
thing, however, that also means you're getting a bunch of (mostly
unnecessary) process reloads, which dilutes the justification for using
FastCGI in the first place.

Another trick, *if* you can afford the overhead, is to stat() a trigger
file of some kind, and if it's newer than it used to be, use that as a
signal to go reload configs, recycle databases, or whatever.

The problem with all methods other than signal() is that you don't find out
it's time to reload/change stuff until there's already a server request
pending (thus waking you up from FCGI_Accept).  This means the user may
have to wait for an expensive reload before getting an answer, even though
there was scads of time to do it since the last request.  The problem with
signal() is that you might catch it at an inconvenient time, e.g., in the
middle of processing.  Judicious use of flags is the easiest solution.
-- 
Tom Neff			Bloomberg, L.P.
<tneff@bloomberg.com>