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