Common Gateway Interface (CGI), which is a standards-based protocol that allows information servers, such as IIS, to interface with external applications. FastCGI was introduced to address the scalability shortcomings of CGI.
CGI
CGI is a protocol that allows information servers to interface with external applications. Because HTTP is stateless, any requests that are made over HTTP create a new instance of the external application in a new operating system process.
Within the new process, the stdin handle is remapped so that it receives request data from the client, the stdout handle is remapped so that it writes response data to the client, and the command line and operating system environment variables are set to provide other server and request information to the CGI process.
The disadvantage with CGI on IIS is the relatively expensive process creation on Windows operating systems. Every HTTP request creates a new process, performs the work inside the CGI application, and shuts down the process. On operating systems with light-weight process creation, performance is bound by the work that is completed inside the CGI application.
On operating systems where process creation is expensive, such as Windows, performance of the CGI application is bound by spinning up the new process. This is the reason why CGI has performed well on a Unix-based platform, but has not been recommended for IIS.
ISAPI – Internet Server Application Programming Interface (ISAPI)
Despite the disadvantage of CGI on Windows, IIS is capable of keeping up with, and often surpassing, the performance of other Web servers. The reason for this is Internet Server Application Programming Interface (ISAPI). Unlike CGI, ISAPI is completely internal to the Web server process. When a new request is made for an ISAPI application, a new process is not created. Instead, the Web server calls an entry point in a DLL that is loaded into the Web server process. If the ISAPI application is written with an understanding of how the operating system threading model works, the performance is extremely fast.
For many years, PHP has run on IIS through both ISAPI and CGI implementations. However, both implementations have disadvantages when running on IIS. As with all CGI applications, the CGI implementation of PHP has a disadvantage due to the performance characteristics of process creation on the Windows OS. The ISAPI implementation has a disadvantage due to threading issues.
When PHP runs as an ISAPI, it runs inside the Web server process in a highly multi-threaded environment. While the PHP implementation is thread-safe, many popular extensions to PHP are not thread-safe. If you use a non-thread-safe extension to PHP with ISAPI, the server can become unstable. Hence, many applications cannot run in the ISAPI PHP implementation, while other applications can run well in this environment.
Fast-CGI
FastCGI offers a solution that delivers both performance and stability. FastCGI allows the host CGI process to remain alive after one request finishes so that the process can be reused for another request. Since the process can be reused many times, the cost of process creation on the Windows OS is no longer an issue.
The technical difference between normal CGI and FastCGI is that FastCGI has a layer in the process that maps the FastCGI protocol into the stdin, stdout and other resources that CGI uses. Many third-party libraries can be linked into existing CGI source code with minor modifications to make them work with FastCGI.
FastCGI on IIS runs on top of ISAPI and can be broken down into the following parts: applications, the application manager, and the FastCGI protocol support code.
Because Web servers handle multiple, concurrent requests, a pool of processes must be available and ready to handle incoming requests. In the FastCGI handler, this pool of processes is called an application (to avoid confusion with IIS applications, this article uses the term “process pool”). There are a number of properties of a process pool that you can manage. For example, you can specify the number of processes in the pool, or the number of requests that a process is allowed to accept before it is shut down and recycled.
The FastCGI handler supports multiple process pools so that you can run more than one kind of FastCGI on a single server. For example, you can configure your server to support both PHP and Ruby on Rails. If you have multiple sites on your server and do not want requests for those sites to share the same processes, you can have the site processes run as different users. The part of the server that handles multiple process pools is called the application manager.
Using the IIS FastCGI support includes the following:
- IIS Web server
- IIS FastCGI extension
- CGI program (such as php-cgi.exe)
The Web server dispatches HTTP requests to your application to the FastCGI component, which in turn launches the CGI program executable, and forwards the request for processing. Once the request is finished and the response is returned back to the server and sent to the client, the CGI process is reused for a subsequent request. This helps to avoid the high performance penalty of starting a new process for each request, which results in better performance and scalability in a production environment.
Install the Fast CGI for IIS 6.0
Download the FastCGI extension for 32-bit and 64-bit Windows XP and Windows Server 2003 here:
http://www.iis.net/extensions/fastcgi
When you run the FastCGI installer, it copies FastCGI-specific files to the “%windir%\system32\inetsrv” folder, and then registers and enables the FastCGI Web server extension. Of the files that the installer copies, note the following:
- fcgiext.dll – This is the actual FastCGI handler that communicates with FastCGI-enabled processes for processing requests.
- fcgiext.ini – This is the configuration file that contains the mapping of file extensions to FastCGI processes. It also contains the configuration of FastCGI process pools.
- fcgiconfig.js – This configures the FastCGI extension. The script updates the fcgiext.ini file, modifies the IIS metabase and recycles the Web service application pools if necessary.
To configure the FastCGI extension to work with PHP:
- Open a command prompt.
- Change the current directory to %windir%\system32\inetsrv.
- Register the PHP CGI program as the one that will be processing .php extensions by running the following configuration script.
cscript fcgiconfig.js -add -section:”PHP” -extension:php -path:”C:\PHP\php-cgi.exe”
Script mappings for the PHP extension in the IIS metabase, and modify the fcgiext.ini file that is located in %windir%\system32\inetsrv.
To create script mapping:
1. Launch inetmgr.exe.
2. Double-click the machine icon for the local computer.
3. Right-click Web Sites and click Properties.
4. Click the Home Directory tab.
5. Click the Configuration… button.
6. Click the Add… button.
7. In the Add/Edit Application Extension Mapping dialog box, click Browse…. Navigate to the fcgiext.dll file that is located in %windir%\system32\inetsrv.
Note: If you need to use FastCGI in 32-bit mode on a 64-bit machine, navigate to %windir%\SysWOW64\inetsrv.
8. In the Extension text box, enter .php.
9. Under Verbs, in the Limit to text box, enter GET,HEAD,POST.
10. Ensure that the Script engine and Verify that file exists check boxes are selected.
11. Click OK.
FastCGI Configuration for Optimal Functionality, Security, and Performance with PHP
IIS identified the set of configuration settings for the FastCGI extension and PHP that would provide optimal functionality and performance for PHP applications when running on Windows by using the FastCGI extension.
To obtain optimal functionality and performance, configure your server as follows:
1. Modify the php.ini file as follows:
* Set fastcgi.impersonate = 1. FastCGI under IIS supports the ability to impersonate the security tokens of the calling client. This allows IIS to define the security context under which the request runs.
* Set cgi.fix_pathinfo=1. cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. Previously, PHP behavior was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not define PATH_INFO. For more information about PATH_INFO, see the cgi specifications. Setting this value to 1 will cause PHP CGI to fix its paths to conform to the specification.
* Set cgi.force_redirect = 0.
2. Set the FastCGI configuration settings for the PHP section by running fcgiconfig.js as follows:
* Set the FastCGI process pool property InstanceMaxRequests to 10000. This setting specifies that the FastCGI extension will recycle php-cgi.exe after it has processed 10000 requests successfully.
> cscript fcgiconfig.js -set -section:”PHP” -InstanceMaxRequests:10000
3. Configure the FastCGI extension to set the PHP_FCGI_MAX_REQUESTS environment variables for the PHP process to 10000.This setting instructs php-cgi.exe to recycle itself after it has processed 10000 requests successfully.
> cscript fcgiconfig.js -set -section:”PHP” -EnvironmentVars:PHP_FCGI_MAX_REQUESTS:10000
To test the PHP application, create and request a info.php
Leave a comment