Using FastCGI with Rails is more complex than it ought to be, but a simple script can make it nearly trivial.

The Lighttpd launcher script is a drop-in alternative to script/server which uses Lighttpd and FastCGI rather than web-brick. Just launch it and go, or pass the --daemon switch to run as a daemon. Lighttpd is generally recognized as one of the highest performing web servers to use wtih Rails. (I ran yum install lighttpd and yum install lighttpd-fastcgi to install the necessary prerequisites on Fedora.)

My only nit is that there should be an option to update the global lighttpd config in etc and restart the main lighttpd service rather than creating a private server; I’m currently working on changes to add this functionality and will share it when ready.

What about running FastCGI with Rails on Apache 2? This appears to be a bad idea in general. James Duncan Davidson reports on consistent problems under load with zombie Rails processes. The post links to a number of different posts from around the web that confirm and diagnose the problem, and suggests alternative configurations including Lighttpd rather than using FastCGI in Apache directly.

My own experience seems to confirm this; my system became unusable under the weight of zombie processes (with a load of greater than 30 and incredible amounts of swapping.) I’ve switched instead to a configuration in which Apache acts a reverse proxy to a Lighttpd/FastCGI/Rails server.