Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13977 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64199 invoked by uid 1010); 2 Dec 2004 07:35:22 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 64112 invoked from network); 2 Dec 2004 07:35:21 -0000 Received: from unknown (HELO mail.zend.com) (80.74.107.235) by pb1.pair.com with SMTP; 2 Dec 2004 07:35:21 -0000 Received: (qmail 7498 invoked from network); 2 Dec 2004 07:35:19 -0000 Received: from localhost (HELO andi-notebook.zend.com) (127.0.0.1) by localhost with SMTP; 2 Dec 2004 07:35:19 -0000 Message-ID: <5.1.0.14.2.20041201233355.02e00300@localhost> X-Sender: andi@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 Dec 2004 23:35:17 -0800 To: Christer Holgersson Cc: internals@lists.php.net In-Reply-To: <20041202072723.GA16419@foo.ardendo.se> References: <5.1.0.14.2.20041201161754.02dfb710@localhost> <20041201181110.GA25044@foo.ardendo.se> <5.1.0.14.2.20041201161754.02dfb710@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] [PATCH] PHP_FCGI_TIMEOUT From: andi@zend.com (Andi Gutmans) I must be missing something. Again, why shouldn't this be the job of whatever is running the FastCGI stuff? So what if it's a web frontend? It should be able to kill the mother implementation so that it also kills its children. At 08:27 AM 12/2/2004 +0100, Christer Holgersson wrote: >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; > > >+ } > > >+ /* ada@riksnet.se: 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) { > > >+ /* ada@riksnet.se: 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