On-demand fastcgi in apache

Steve Kann (stevek@io360.com)
Mon, 28 Oct 1996 17:23:26 -0500 (EST)

From: Steve Kann <stevek@io360.com>
Message-Id: <199610282223.RAA01838@spheara.io360.com>
Subject: On-demand fastcgi in apache
To: fastcgi-developers@openmarket.com
Date: Mon, 28 Oct 1996 17:23:26 -0500 (EST)

I've been thinking all along about this, and just now read mark's notes
in the latest mod_fastcgi.c 

A few notes:

1) I understand that using the "mbox" file is simple, but I think it
seems kludgy: There must be a way to do this with a more modern IPC
method?  (I know we need to avoid race conditions of multiple writers --
maybe a Unix Datagram socket? )

2) as far as how to manage a "pool" of on-demand fastcgi apps, there is
a lot to be discussed.  For starters, the idea would still be very
useful even with a very simple algorithm:

something like this would be just fine:

Have a min/max/initial number of processes.
If all are busy start a predefined # more.

For me, I stopped using fastcgi because of the administrative headaches
of having to restart all the servers whenever a fastcgi is added,
removed, or simply renamed.  The decrease in request latency was nice,
but my server has already failed to restart on two different occasions
where some silly person accidentally removed my .fcgi script.

Having dynamically started fast-cgi applications would give me these
benefits:

1) don't have to specify AppClasses for specific fastcgi programs
	(although, an advanced user might want to do so to give "hints" 
	to a dynamic management algorithm)

2) server will still start without .fcgi being there

In general, this will make the whole process more of a "no-brainer".

-SteveK

--- 
     Steve Kann   i/o 360 digital design   841 Broadway, Suite 502
  PGP 1024/C0145E05  F2 D6 24 83 9E 52 9A 61  AA BB 97 61 5C A1 B8 CE
       Personal:stevek@SteveK.COM    Business: stevek@io360.com