NOTE: This article was written in 2005. For more up-to-date information on deplyoment, please see http://dev.catalyst.perl.org/wiki/deployment

As a companion to Day 7's mod_perl article, today's article is about production FastCGI deployment.

FastCGI performs equally as well as mod_perl. Don't let the 'CGI' fool you; your app runs as multiple persistent processes ready to receive connections from the web server.

When using external FastCGI servers, your application runs as a standalone application server. It may be restarted independently from the web server. This allows for a more robust environment and faster reload times when pushing new app changes. The frontend server can even be configured to display a friendly "down for maintenance" page while the application is restarting.

You can launch your application on multiple backend servers and allow the frontend web server to load-balance between all of them. And of course, if one goes down, your app continues to run fine.

Each FastCGI application is a separate process, so you can run different versions of the same app on a single server.

Since your app is not running inside of Apache, the faster mpm_worker module can be used without worrying about the thread safety of your application.

With FastCGI, there are more things to monitor and more processes running than when using mod_perl.

mod_fastcgi for Apache is a third party module, and can be found at http://www.fastcgi.com/. It is also packaged in many distributions, for example, libapache2-mod-fastcgi in Debian.

    # Serve static content directly
    DocumentRoot  /var/www/MyApp/root
    Alias /static /var/www/MyApp/root/static

    FastCgiServer /var/www/MyApp/script/myapp_fastcgi.pl -processes 3
    Alias /myapp/ /var/www/MyApp/script/myapp_fastcgi.pl/

    # Or, run at the root
    Alias / /var/www/MyApp/script/myapp_fastcgi.pl/

The above commands will launch 3 app processes and make the app available at /myapp/

While not as easy as the previous method, running your app as an external server gives you much more flexibility.

First, launch your app as a standalone server listening on a socket.

    script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 5 -p /tmp/myapp.pid -d

You can also listen on a TCP port if your web server is not on the same machine.

    script/myapp_fastcgi.pl -l :8080 -n 5 -p /tmp/myapp.pid -d

You will probably want to write an init script to handle starting/stopping of the app using the pid file.

Now, we simply configure Apache to connect to the running server.

    # 502 is a Bad Gateway error, and will occur if the backend server is down
    # This allows us to display a friendly static page that says "down for
    # maintenance"
    Alias /_errors /var/www/MyApp/root/error-pages
    ErrorDocument 502 /_errors/502.html

    FastCgiExternalServer /tmp/myapp -socket /tmp/myapp.socket
    Alias /myapp/ /tmp/myapp/

    # Or, run at the root
    Alias / /tmp/myapp/

Lots more information is available in the new and expanded FastCGI docs that will be part of Catalyst 5.62. For now you may read them here: http://dev.catalyst.perl.org/file/trunk/Catalyst/lib/Catalyst/Engine/FastCGI.pm

--Andy Grundman