[Catalyst] Why use external FastCGI apps?

[Mitchell Jackson]

I experienced similar behavior with Catalyst when using external FastCGI 
controlled by init.d under two FC8 boxes. 

When the app was restarted, it never came back.  The processes were 
still there, but the socket became non-responsive.  Issuing another 
start command would bring up another copy of the app that worked, but 
the old processes were still running on the system and eventually caused 
the running live app to come to a crawl.  This lead to a daily purge 
cycle where, in the mornings before users started hitting the system, I 
would stop the app and then check the process list for any app processes 
still hanging around and kill them.  Generally, only kill -9 would do 
the trick.  On really busy days, I might have to do this purge process 
later in the afternoon as well. And after a few weeks, no matter what, 
the server would run like a whooped dog until it was rebooted.

When I switched to mod_fcgid the server became stable, and always fast 
all the time.  There was much rejoicing.

I chose mod_fcgid instead of mod_fastcgi because mod_fastcgi is being 
maintained as an official fedora repository package and mod_fastcgi 
isn't.  That made mod_fcgid the easiest thing for me from the server 
deployment and maintenance viewpoint.

I don't consider the apache configuration to be difficult to manage.  I 
maintain a separate config file for each virtualhost, and it's just as 
easy to swap values in those files and issue 'service httpd reload' as 
it is to switch around your production and head init.d scripts and issue 
init.d restarts.  I haven't experienced any dropped requests using this 
method when deploying a new revision of the app.

 From the discussions in this thread it sounds like there could be 
better benefits using FastCGIExternalServer, but it will probably be a 
while before I give that route another try.

/Mitch


Speaking of kill -9... http://www.youtube.com/watch?v=Fow7iUaKrq4


Felix Antonius Wilhelm Ostmann wrote:
> Perhaps someone can help me with my problem and external FastCGI :-/
>
> i have a fastcgi start/stop script (dont know anymore from which 
> howto), but i cant make fastcgi_server.sh restart
>
> he say he stoped and started properly, but after that the socket is 
> broken?!?! i always need to stop, wait 5 seconds and start then :-/
>
> is there another start/stop daemon out there?
>
>
>
> Matt S Trout schrieb:
>> On Thu, Feb 07, 2008 at 11:46:36AM -0500, Matt Pitts wrote:
>>  
>>> I just got advise from mst to not use mod_fcgid in production 
>>> because it
>>> doesn't support external fastcgi and this is the way to do HA apps. I
>>> wanted to ask some questions and hear some arguments. I know there's
>>> some existing traffic on the list about this, but I thought some fresh
>>> info would be nice.
>>>
>>> We're currently running a Cat app under mod_fcgid in production that
>>> handles about a million hits a day b/t Cat and static files.
>>>
>>> Why did we chose mod_fcgid? Well, I tried playing around with
>>> mod_fastcgi for awhile and had problems getting the config straight -
>>> admittedly due to a lack of knowledge on my part. Then I read some
>>> tidbits about mod_fcgid being "better", so I tried it out and it "just
>>> worked" and has been "just working" ever since.
>>>
>>> Why is it so much better to have fastcgi as an external process? Is it
>>> because this is the only way to realistically to PAR-based deployments?
>>>
>>> What's wrong with having mod_fcgid do its process management.
>>>     
>>
>> Because then you restart the FastCGI processes when you restart the web
>> server.
>>
>> With external, you can have
>>
>> - webserver
>> - fastcgi for app version N
>> - fastcgi for app version N+1
>>
>> all managed separately.
>>
>> that means you can update by
>>
>> - start N+1
>> - change apache config to point to N+1
>> - apachectl graceful
>> - stop N
>>
>> which allows you to update with zero downtime - without even dropping a
>> single request on the floor.
>>
>> And if something goes wrong, you can perform the process in reverse 
>> just as
>> easily.
>>
>> I consider this essential for heavily-used applications since having 
>> a 5+
>> second window of "mid-upgrade" when the app doesn't respond is a pain in
>> the ass for users.
>>
>> For less heavily used applications I don't care - apache starts the 
>> fastcgi
>> handlers for shadowcat.co.uk because it's mostly a news + brochureware
>> type site so a few seconds' downtime every so often really just doesn't
>> matter to us.
>>
>>   
>
>