FastCGI is a protocol for interactivity with a web server. FastCGI is a variation of the older Common Gateway Interface (CGI); FastCGI’s primary goal is to reduce the overload associated with web server interfacing and CGI programs, allowing a server to handle multiple requests for web pages at the same time.
CGI is a protocol for interfacing external applications to web servers. CGI applications run in a separate process that is created at the beginning of each request and it is closed at the end of it. This “new process per request” model makes CGI very simple to implement, but through it the efficiency and scalability goes down.
At high uploads, consumption for creating and destroying the operating system process becomes significant and limits the scalability. To improve scalability for CGI, Open Market has developed FastCGI and introduced it for the first time in server production in the mid-1990s. Open Market originally developed FastCGI as a competitive response to the Netscape’s owner for API in-process (NSAPI) for web application development.
Although originally developed by the Open Market, FastCGI has been adopted by many web server manufacturers. FastCGI had to cope with the competition of other techniques that also aimed to speed up and simplify server-subprogram communications that were not following the CGI paradigm.
Apache modules such as mod_perl and mod_php appeared at about the same time and seemed to replace CGI better, allowing for a closer integration with the web base. In terms of performance: FastCGI is faster than suPHP and mod_php is faster than suPHP and FastCGI (but it depends on many factors, so it’s not a rule);
suPHP
For each request received, the server creates a new process. The web server takes the information (http headers, hostname, ip address, cookie) and passes it to suPHP which processes them according to the environment (suPHP_UserGroup, suPHP_ConfigPath in the case of suPHP or environment defined by wrapper in case of CGI). The web server serves the processed content to the user. When the request is totally processed (or as the timeouts are defined), the php process ends
Pros:
– Apache can be threaded safe (worker), being separated from php
– Can be isolated by user/environment.
As a disadvantage I would include the fact that it does not support “php_value” stuff in “.htaccess”
FastCGI
The web server creates a predefined number of processes waiting for connections. When the web server receives a request, it is processed by the processes that are already running. FastCGI processes send the processed content and the error messages to the web server on the same connection. When the request is processed, FastCGI processes close the connection and remain on hold for new requests.
Pros:
– Apache can be threaded safe (worker), being separated from php
– Can be isolated by user/environment.
As a disadvantage I would include the fact that it does not support “php_value” stuff in “.htaccess”
mod_php
PHP scripts are processed directly by the web server via mod_php.
Pros:
– As an advantage: “php_value” and other php settings can be used directly from “.htaccess” (if allowed by AllowOverride or per Directory – Apache)
Disadvantages:
– Apache can not be run with Worker and PHP cannot be compiled with threaded safe because many modules are not working
– Memory consumption is high
– It can not be separated by environments by user, everything runs with the same user as apache, therefore, from the security point of view it is weaker than suPHP and FastCGI