Re: Issued with Apache+mod_fastcgi+PHP

Have you tried setting up your dynamic proc settings to wait longer before 
forking off more processes?  We're running an older snap, but we have this set 
up:

FastCGIConfig -startDelay 180 -restart -appConnTimeout 181 -idle-timeout 180 
-maxClassProcesses 3 -init-start-delay 20

Which means, wait 180 seconds between instances, and wait 181 seconds for your 
application to wake up (the first time) and to wait 20 seconds between starts.

PHP...sigh.  If you're ONLY using FastCGI for PHP, you should be able to set 
-maxClassProcesses to 1, and play with the others until you're satisfied with 
the performance.  The defaults should be good for basic PHP stuff, and PHP 
starts pretty quick.

David.

-----

On Tue, 21 Mar 2006, Matt wrote:

>
> Unfortunatly, static isn't an option to me as we have hundreds of users and
> run everything under suexec.
>
> I'm glad at least someone else has experienced the issue...  If anyone has a
> fix workaround, that would be great ;)
>
>
>
> - Matt
>
>
> -----Original Message-----
> From: Chris Lightfoot [mailto:chris-Fh87UKZVeM/RBZ/RhJC5oVcZoxXaR/[email protected]] On Behalf Of
> Chris Lightfoot
> Sent: Tuesday, March 21, 2006 7:35 AM
> To: Matt
> Cc: fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> Subject: Re: [FASTCGI] Issued with Apache+mod_fastcgi+PHP
>
> On Sun, Mar 19, 2006 at 07:59:00PM -0500, Matt wrote:
>    [...]
>> What occurs is that with certain (slow) scripts, PHP will continously
> spawn
>> every n seconds.  I believe I've correlated n to the -startDelay setting,
> so
>> if its set to 3, it spawns a PHP process every 3 seconds, if its 10, it
>> spawns one every 10 seconds.  In any case, the old processes are not
> killed
>> and you end up with x amount of processes running, to serve a single page
>> (and obviously one one of the procs is actually returning results).  I
> fear
>> that this behavior will result in a single page will consume the resources
>> alotted.
>>
>> Any suggestions on how to workaround this situation, or am I missing some
>> inherit setting that may help to appease the situation?   I have
>> experimented with most of the settings above, but wasn't able to get
>> acceptable behavior.
>>
>> I've tested it on a server with 3 sites and a server with 300, and it
>> behaves the same in both.
>
> yeah. We had this problem with RT, which uses 50--100MB of
> unshared memory for each instance (it's a gigantic perl
> program); it processes email by having it passed in an
> HTTP POST to the RT application, and then does various
> SpamAssassin checks which can take a while (waiting for
> DNS results, I suspect, but I got kind of bored of
> debugging this at that point). So during a ~30s period
> while the first instance of mason-handler.fcgi is
> processing a mail, the process manager spawns another
> instance every 3s. Obviously if at this point you don't
> have half a gigabyte of spare memory knocking around
> you're in a certain amount of trouble.
>
> We fixed this by running the application as a static
> FastCGI process with a fixed limit of three extant
> processes, though this is hardly ideal. I spent a little
> while reading the process manager code to try to
> understand its strategy (obviously it oughtn't to start
> further instances of the application unless there're
> further requests to process, but it does anyway); however,
> the code's a bit tangled and I try to avoid hacking on
> nonfree software for no reward if I can possibly avoid it.
>
> I take it there hasn't been any progress in relicensing
> mod_fastcgi?
>
> -- 
> Chris Lightfoot
> mySociety
>
> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/
>
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/