If you are running the FastCGI version of PHP it will start
up a number (default 8) of "child" PHP interpretors that will
wait around indefinitely for work to do, and the "mother" FastCGI
process will automatically restart any process that terminates
(and automatically restart every child after a default of 500
requests).
If you are using a web frontend that dynamically starts the
FastCGI processes when needed it is totally unnecessary for
the FastCGI:s to hang around when there is no demand for them,
thus this patch. It will terminate the mother FastCGI and all
children after PHP_FASTCGI_TIMEOUT seconds with no request to
any of the children, and whenever there is demand for the
FastCGI again the web frontend will restart the processes.
This is excellent if you have a lot of scripts that are seldom
invoked, but that you want to run as FastCGI:s when there is
actual demand for them, and that are chroot:ed so that you have
a diffent FastCGI PHP started for each of them. In this case
you _do_ want them to self-termninate when there is no demand.
Cheers,
/C
On Wed, Dec 01, 2004 at 04:18:37PM -0800, Andi Gutmans wrote:
> I don't see why this patch is needed. It's the FastCGI implementation's job
> to do the right thing and terminate the processes according to some kind of
> strategy. The FCGI processes shouldn't self destruct.
>
> Andi
>
> At 07:11 PM 12/1/2004 +0100, Christer Holgersson wrote:
>
> >Included is a patch that adds a PHP_FCGI_TIMEOUT that works
> >somewhat akin to PHP_FCGI_MAX_REQUESTS. With PHP_FCGI_TIMEOUT
> >set to 300 the whole fcgi process will terminate after 300 sec
> >with no request to any of the worker children - great for those
> >seldom used dynamically created fcgi scripts.
> >
> >Cheers,
> > /Chris
> >
> >PS. The patch works just as well in 5.0.2 as in 4.3.9.
> >
> >
> >diff -rub php-4.3.9/sapi/cgi/cgi_main.c php-4.3.9-ada/sapi/cgi/cgi_main.c
> >--- php-4.3.9/sapi/cgi/cgi_main.c 2004-07-15 00:38:18.000000000 +0200
> >+++ php-4.3.9-ada/sapi/cgi/cgi_main.c 2004-12-01 09:00:58.595259999 +0100
> >@@ -946,6 +946,24 @@
> > /* We should exit at this point, but MacOSX doesn't seem to */
> > exit( 0 );
> > }
> >+
> >+
> >+static int php_fcgi_timeout = 0;
> >+
> >+static void reset_timeout()
> >+{
> >+ alarm(php_fcgi_timeout);
> >+ /* fprintf(stderr, "FastCGI: reset timeout\n"); */
> >+ signal(SIGUSR1, reset_timeout);
> >+}
> >+
> >+static void handle_timeout()
> >+{
> >+ /* fprintf(stderr, "FastCGI: timeout\n"); */
> >+ fastcgi_cleanup(SIGALRM);
> >+ exit(0);
> >+}
> >+
> > #endif
> >
> > /* {{{ main
> >@@ -980,6 +998,7 @@
> > #endif
> >
> > #if PHP_FASTCGI
> >+ int php_fcgi_pid = getpid();
> > int max_requests = 500;
> > int requests = 0;
> > int fastcgi = !FCGX_IsCGI();
> >@@ -1178,6 +1197,20 @@
> > }
> > }
> >
> >+ /* How long all children can be idle before terminating */
> >+ if( getenv( "PHP_FCGI_TIMEOUT" )) {
> >+ php_fcgi_timeout = atoi( getenv(
> >"PHP_FCGI_TIMEOUT" ));
> >+ if( !php_fcgi_timeout ) {
> >+ fprintf( stderr,
> >+ "PHP_FCGI_TIMEOUT is not valid\n"
> >);
> >+ return FAILURE;
> >+ }
> >+ /* [EMAIL PROTECTED]: children signal parent when
> >they do work, */
> >+ /* which resets the timeout value */
> >+ signal(SIGALRM, handle_timeout);
> >+ signal(SIGUSR1, reset_timeout);
> >+ }
> >+
> > /* make php call us to get _ENV vars */
> > php_php_import_environment_variables =
> >php_import_environment_variables;
> > php_import_environment_variables =
> >cgi_php_import_environment_variables;
> >@@ -1305,6 +1338,8 @@
> >
> > while (!fastcgi
> > || FCGX_Accept_r( &request ) >= 0) {
> >+ /* [EMAIL PROTECTED]: let parent know we have work
> >to
> >do */
> >+ if (php_fcgi_timeout) kill(php_fcgi_pid, SIGUSR1);
> > #endif
> >
> > #if PHP_FASTCGI
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Christer Holgersson
CTO, Ardendo AB
www.ardendo.se
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
