FastCGI in IIS7. (Continued)

This post is a continuation of the previous one about FastCGI and IIS7, in Windows 2008 Beta 3 and Windows Vista, FastCGI is included as native support, which allows running PHP applications and other Script languages on Windows machines with extremely high performance and stability, even in production environments. The FastCGI CTP preview 2 can also be installed on IIS 5.1 and 6.0.

In this post, beyond the instructions on how to install a PHP application on Windows Vista or Windows 2008, I will talk a little about the reasons why application performance increases when using FastCGI.

First a little Background.

Common Gateway Interface (CGI)

The de facto standard for applications on web servers is CGI, which was initially implemented by the NCSA server. CGI has several benefits:

· Simplicity. it is easy to understand

· Language Independence. CGI applications can be written in any language

· Process Independence. Since applications run in separate processes, problematic applications cannot damage the web server or access the server's internal and private state.

· Open Standard. Some form of CGI has been implemented in all web servers

· Architectural Independence. CGI is not tied to any particular server architecture

CGI also has some important deficiencies. The main problem is performance: because a new process is created for each request and it is removed when the request is completed, efficiency is poor.

CGI also has limited functionality: it only supports the Role “responder”, where the application generates the response that is sent to the client, CGI programs cannot be associated with other parts of request processing such as authorization or error logging.

Server APIs

In response to CGI's performance problems, different companies have developed APIS for their servers. The two most relevant are Netscape's NSAPI and Microsoft's ISAPI. The Apache server also has an API.

Applications associated with the server API can run much faster than CGI programs. The Startup / initialization problem has been improved, since the application runs in a dedicated server process and persists between requests. Web server APIs offer much more functionality than CGI, anyone can write extensions that perform access control, access the server log files, and can connect at other stages of request processing.

So what is FastCGI?

The FastCGI interface combines the best aspects of CGI and proprietary APIs. Like CGI, FastCGI applications run in separate and independent processes. The advantages of FastCGI’ include:

· Performance. FastCGI processes are persistent –they are reused to handle multiple requests. – This solves CGI's performance problems of creating new processes for each request.

· Simplicity, easy migration from CGI. The FastCGI application library simplifies the migration of existing CGI applications. Applications built with FastCGI can run CGI programs for compatibility with older Web Servers.

· Language Independence. Like CGI, FastCGI applications can be written in any language.

· Process Independence. A faulty FastCGI application cannot corrupt the web server core or any other application. A FastCGI application cannot steal any secrets (such as session keys for encryption) from the Web server.

· Non-proprietary. FastCGI is supported by all the Open Source products on the Market, including apache, NCSA and now it is supported by commercial servers from Microsoft and Netscape.

· Architectural Independence. The FastCGI interface is not tied to any particular server architecture. Any server can implement the FastCGI interface. Likewise, FastCGI imposes no architecture on the application: applications can be single or multi-threaded, regardless of the web server's threading architecture.

· Support for distributed computing. FastCGI provides support for running applications remotely, which is useful for load distribution and external management of web sites.

The FastCGI interface

The functionality provided by the FastCGI interface is very similar to that provided by CGI. To better understand the FastCGI protocol. The processing of CGI requests is like this:

1. For each Request, the server creates a new process and the process initializes itself.

2. The web server passes the request information (such as remote host, user name, HTTP headers, etc) to the CGI program's environment variables.

3. The web server sends any client input (such as values entered by the user in an HTML form) to the standard input of the CGI program.

4. The CGI program writes any output to be returned to the client as standard output. The error information is written by the web server.

5. When the CGI process closes, the request is complete.

FastCGI is conceptually very similar to CGI, with two main differences:

· FastCGI processes are persistent: after finishing a request, the processes remain waiting instead of ending.

· Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the environment information, the standard input, the standard output and error over a full-duplex connection. This allows FastCGI programs to run on remote machines, using TCP connections between the web server and the FastCGI applications.

The processing of a request in a single-threaded FastCGI application occurs like this :

1. The Web server creates the FastCGI application to handle requests to the server. The process can be created at startup or created on demand.

2. The FastCGI program initializes itself, and waits for a new connection with the web server.

3. When a request from a client arrives, the web server opens a connection to the FastCGI processes. The server sends the environment information and the standard input over the connection.

4. the FastCGI process sends the standard output and the error information back to the server over the same connection.

5. When the FastCGI process closes the connection, the request is complete. The FastCGI process remains waiting for another connection from the web server.

FastCGI can run locally (on the same machine as the web server) or remotely. For local applications, the server uses a full-duplex pipe to connect with the FastCGI application process. For remote applications, the server uses TCP connections.

FastCGI applications can be single-threaded or multi-threaded. for single threaded applications, the web server maintains a pool of processes (if the application runs locally) to handle client requests. The Pool size is configurable by the user. Multi-threaded FastCGI applications can receive multiple connections from the web server and handle them simultaneously in a single process. (In this way languages, with support for multi thread, garbage collection, among others, make them natural languages to implement multithreaded applications using FastCGI)

Application Roles.

An important problem with CGI is its limited functionality: CGI programs only provide simple responses to the request. FastCGI provides extended functionality with support for three different application roles:

· Responder. this is the basic role in FastCGI and corresponds to the basic functionality offered by CGI today.

· Filter. FastCGI applications filter the files requested from the web server before they are sent to the client.

· Authorizer. The FastCGI program makes an access control decision for the request ( for example by performing a database lookup of the User/password type).

Other roles will be defined in the future. For example, a role “logger” could be useful, where the FastCGI program could receive the server log record for real-time processing and analysis.

How fast is FastCGI?

The answer depends on the application, some tests done on the internet show the following:

In this measurement a file, a CGI request and a fastCGI request are used, using an application that returns a fixed number of bytes.

File

21ms + 0.19ms per Kbyte

FastCGI

22ms + 0.28ms per Kbyte

CGI

59ms + 0.37ms per Kbyte

With this data we can try to calculate the speed after migrating a typical database CGI application to FastCGI, assuming that the application takes 50ms to initialize the database connections and generates 5k of data. The final results can be calculated like this:

CGI

59ms + 50ms + (0.37ms)(5) = 111ms

FastCGI

22ms + (0.28ms)(5) = 23ms

In this test, FastCGI had a 5x performance advantage over CGI, mostly due to not having to create and start a new process for each request.

In summary

FastCGI is a standard protocol that allows executables using CGI Frameworks to interact with a Web Server.

The biggest difference with the Standard CGI Protocol is that FastCGI reuses CGI Processes for multiple requests, which increases performance compared to CGI.

IIS support for FastCGI allows IIS to host regular CGI programs such as PHP, or Ruby On Rails, using the FastCGI protocol, offering high performance and stability in production environments

To use FastCGI support in IIS three elements are required:

· El web server IIS (IIS5.1, IIS6, and IIS7).

· The FastCGI component for IIS

· THE CGI program that will be hosted.

How does it work?

The web server dispatches the http requests made to your application using the FastCGI component, which in turn launches the CGI executable program and forwards the request to be processed. Once the request is processed and the response is finalized and returned to the server and the client, the CGI process is used for subsequent calls. This avoids the high performance penalties of starting a new process for each request, resulting in much better performance and scalability in production environments.

The FastCGI protocol is standard if you want to have more information about FastCGI you can see more here. http://www.fastcgi.com/devkit/doc/fcgi-spec.html.

The FastCGI package is fully compatible with the current and official PHP 5.x distribution available for Windows from www.php.net/downloads. You can also use the Fast CGI preview with the existing PHP 5.x installation (however using the ThreadSafe version increases performance by up to 30%)

Version 5.2.3 also contains the improvements developed by Zend to improve the performance of the PHP engine on Windows.

I hope it is Helpful

Juan Carlos Peláez

MCTS

Member of the Microsoft Speaker Group Andino

Member of the Microsoft Influencers Group of Colombia.

Keywords: PHP, FastCGI, Windows Vista, Windows 2008, IIS7, Architecture.