[Catalyst] Why use external FastCGI apps?

[Matt Pitts]

Although I haven't had any experience yet with *external* fastcgi, I'm
feeling this approach as well, mainly because it allows me to "hang my
hat" on the starting/stopping/reloading of apache. I'm also trying to
treat an Apache vhost like an "appliance" that I can drop anywhere. I
basically have *everything* related to a single vhost organized under a
standard structure and I keep it all in Subversion.

This way, deploying a site to a different machine is
 - get vhost "appliance" from subversion
 - symlink vhost conf file into apache vhosts.d
 - sync logs if necessary
 - apache reload

I know my model isn't perfect, but if I use external fastcgi then it
adds an "easily looked over" step - create/symlink some fastcgi init
script.

The only things that will definitively push the use of external fastcgi
are: if I cannot get mod_fcgid to work with PAR files; or if I'm happy
with external fastcgi testing/memory usage and can integrate it into my
vhost model without too much unhappiness.

v/r

-matt pitts


> -----Original Message-----
> From: Mitchell Jackson [mailto:mitch.lists at onsitesquad.com]
> Sent: Monday, February 11, 2008 10:58 AM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Why use external FastCGI apps?
> 
> 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.
> >>
> >>
> >
> >
> 
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
> archive.com/catalyst at lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/