The fcgi handler makes queries to FastCGI servers, such as PHP, Ruby on Rails or Django in order to get the request response. FastCGI is scalable and language independent enhancement to CGI that provides high performance without limitations of server specific APIs and reduced overhead. It is basically the same thing as CGI but much faster.
This module accepts all the general CGI parameters. Aside, it needs a balancer to be configured. It is the piece of configuration that points the handler where to find the FastCGI servers.
For most of the cases there will be only one FastCGI server though. In that scenario the way to go would be to configure the handler to use a Round Robin balancer and configure a single host or interpreter (it has no performance penalty).
To set up the general gateway options, read about the common parameters shared with the CGI handler.
To set up the balancing options read the Balancers section for general information and the Round robin section for specifics.
Note that the FastCGI and SCGI handlers can directly use Unix sockets. You only have to specify a full path to the socket instead of the host:port, and everything will simply work.
Refer to the Cookbook if you want specific examples on how to configure this handler. The recipe about setting up PHP is a good starting point.
There a are two handlers currently implementing the FastCGI protocol: "fcgi" and "fastcgi".
The "fastcgi" module also implements the FastCGI protocol. It is a more complete implementation than "fcgi" although it is also more complex. Actually, fcgi became the standard choice because the PHP interpreter kind of buggy when it has to demultiplex multiple requests from the same socket.
The "fastcgi" handler will eventually become the default option because it is faster and more standard-compliant. However, at the moment "fcgi" is a better option.