[Catalyst] Why use external FastCGI apps?

Felix Antonius Wilhelm Ostmann ostmann at websuche.de
Fri Feb 8 08:50:05 GMT 2008


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.
>
>   


-- 
Mit freundlichen Grüßen

Felix Antonius Wilhelm Ostmann
--------------------------------------------------
Websuche   Search   Technology   GmbH   &   Co. KG
Martinistraße 3  -  D-49080  Osnabrück  -  Germany
Tel.:   +49 541 40666-0 - Fax:    +49 541 40666-22
Email: info at websuche.de - Website: www.websuche.de
--------------------------------------------------
AG Osnabrück - HRA 200252 - Ust-Ident: DE814737310
Komplementärin:     Websuche   Search   Technology
Verwaltungs GmbH   -  AG Osnabrück  -   HRB 200359
Geschäftsführer:  Diplom Kaufmann Martin Steinkamp
--------------------------------------------------




More information about the Catalyst mailing list