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