Pros

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.

App 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.

Load-balancing

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

Multiple versions of the same app

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

Can run with threaded Apache

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.

Widely supported.

FastCGI is compatible with many server implementations, not just Apache.

Cons

More complex environment

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

Standalone FastCGI Server

To start your application in server mode, install the FCGI::ProcManager module and then use the included fastcgi.pl script.

    $ script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 5

Command line options for fastcgi.pl include:

    -d -daemon     Daemonize the server.
    -p -pidfile    Write a pidfile with the pid of the process manager.
    -l -listen     Listen on a socket path, hostname:port, or :port.
    -n -nproc      The number of processes started to handle requests.

See below for the specific web server configurations for using the external server.

Apache

nginx

lighttpd

Microsoft IIS