Re: Make FastCGI reliable

The changes to the FastCgiConfig line worked pretty good.
Most of the times when FastCGI fails is when someone tries to upload a 
too big photo for it's own connection :P
The mail function also seems to be delaying a php script so now and 
then. But I don't think these cases can be caught by setting up a time 
limit on a php script since FastCGI fails a fcgi request up on idle time 
and a time limit does not account for blocking io, etc.

How should I be able to catch these cases. Only customizing the 500 
error wouldn't be sufficient because the user thinks the error is at my 
side, but instead the user is uploading a too big photo for example.

p.s. a worstcase situatie would be that all fastcgi processes are busy 
handling file uploads from very slow users. Do you have suggestion to 
prevent such script from clogging up the functionlity of the site?


Regards,

Frank de Bot



Matt wrote:
> Frank,
> 
> We've struggled with PHP/FastCGI, but I think we've finally got a solid
> configuration.  We are a web host, so we host quite a few sites on a server,
> hence we must use dynamic processes.
> 
> Our FastCgiConfig line:
> FastCgiConfig -idle-timeout 300 -listen-queue-depth 512 -maxClassProcesses 3
> -maxProcesses 90 -multiThreshold 50 -singleThreshold 25 -flush -pass-header
> HTTP_AUTHORIZATION
> 
> #!/bin/sh
> export PHP_FCGI_CHILDREN=3
> exec /usr/local/bin/php 
> 
> 
> A couple things that I've learned:
> 
> The "exec" line is VERY important.  Without it, php is spawned with a new
> process ID, that the FastCGI proc manager does not know about.  Thus, when
> FCGI kills the pid, it only kills the shell script, and not the actual PHP
> script.
> 
> PHP-Fastcgi is designed to function with the PHP_FCGI_CHILDREN option set.
> There are a few places in the code that things break (eg flush() statement)
> if it doesn't have children.  Not setting it does create some issues, that
> while patchable, well, we still had problems ;)
> 
> Also note that the main PHP proc will spawn a number of children equal to
> the PHP_FCGI_CHILDREN number.  In the above example, FastCGI will spawn a
> PHP process upon request, and that PHP process will spawn 3 more children,
> for a total of 4 php processes (3 that actually process request).  Should
> the script be slow and not respond to FastCGI within the startDelay, then
> FastCGI will spawn another PHP process, which will spawn another 3 procs,
> etc. until maxClassProccesses is reached.  In the agove configuration, a
> single user may have 12 PHP processes, 9 processing, which I find is PLENTY
> for even the busiest sites.  Worst case is that slow scripts will tie up a
> particular PHP process, and so if they have 9 slow scripts running,
> additional requests will wait... But from what I've seen, these scripts are
> more broken than anything ;)
> 
> I haven't experimented with PHP5 just yet.  I do have PHP4 with a few
> patches, and I hadn't determined the need with the new FastCGI code.
> 
> I did apply this patch:
> http://bugs.php.net/bug.php?id=36158
> 
> Which ensures that PHP will complete processing a request should it be
> signalled for termination.  Otherwise, if FCGI signals the proc for term, it
> will just die, and stop output immediately, leaving half rendered pages.
> 
> 
> Lemme know if this helps at all...
> 
> 
> Matt Houston
> Systems Administrator
> Successful Hosting
> [email protected]
> http://www.SuccessfulHosting.com
> Toll-Free: +1.866.494.5096
> =================================
> The Success behind your web site!
> ================================= 
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/