[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