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:[EMAIL PROTECTED] > 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@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail- > archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/