Figure 1
+ + Open Market, Inc. +
++
++ April 1996 +
++ The surge in the use of the Web by business has created a tremendous need for server extension applications + that create dynamic content. These are the applications that will allow businesses to deliver products, + services, and messages whose shape and content are in part determined by the interaction with, and knowledge + of, the customers to which they are delivered. +
++ This important movement away from static Web content is pushing the limits and exposing the weaknesses of the + environment in which these applications are currently bound: CGI (Common Gateway Interface). Most importantly + it does not offer the performance these applications require. A new communication infrastructure is needed to + connect Web servers with these new applications. This is what led Open Market to develop FastCGI. +
++ FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI, + without introducing the overhead and complexity of proprietary APIs (Application Programming Interfaces). +
++ This paper assumes that the reader has basic familiarity with Web technology and developing Web applications. +
++ The de facto standard interface for Web server applications is CGI, which was first implemented in the NCSA + server. CGI has many benefits: +
++ CGI also has some significant drawbacks. The leading problem is performance: Since a new process is created + for each request and thrown away when the request is done, efficiency is poor. +
++ CGI also has limited functionality: It only supports a simple "responder" role, where the + application generates the response that is returned to the client. CGI programs can't link into other + stages of Web server request processing, such as authorization and logging. +
++ In response to the performance problems for CGI, several vendors have developed APIs for their servers. The + two most notable are NSAPI from Netscape and ISAPI from Microsoft. The freely available Apache server also has + an API. +
++ Applications linked into the server API may be significantly faster than CGI programs. The CGI + startup/initialization problem is improved, because the application runs in the server process and is + persistent across requests. Web server APIs also offer more functionality than CGI: you can write extensions + that perform access control, get access to the server's log file, and link in to other stages in the + server's request processing. +
++ However, APIs sacrifice all of CGI's benefits. Vendor APIs have the following problems: +
++ The FastCGI interface combines the best aspects of CGI and vendor APIs. Like CGI, FastCGI applications run in + separate, isolated processes. FastCGI's advantages include: +
++ The following sections describe the FastCGI interface, protocol, application library, and support in Open + Market's WebServer products. +
++ The functionality provided by the FastCGI interface is very similar to that provided by CGI. To best + understand the FastCGI protocol, we review the CGI interface here. Basic CGI request processing proceeds as + follows: +
++ FastCGI is conceptually very similar to CGI, with two major differences: +
++ Request processing in a single-threaded FastCGI application proceeds as follows: +
++ FastCGI applications 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 to the FastCGI application process. For remote + applications, the server uses a TCP connection. +
++ FastCGI applications can be single-threaded or multi-threaded. For single threaded applications, the Web + server maintains a pool of processes (if the application is running locally) to handle client requests. The + size of the pool is user configurable. Multi-threaded FastCGI applications may accept multiple connections + from the Web server and handle them simultaneously in a single process. (For example, Java's built-in + multi-threading, garbage collection, synchronization primitives, and platform independence make it a natural + implementation language for multi-threaded FastCGI applications.) +
++ FastCGI's ability to run applications remotely (over a TCP connection) provides some major benefits. These + benefits are described in this section, along with some of the security issues that affect remote FastCGI + applications. +
++ Applications that run on organizational (external) Web servers and depend on internal databases can be a + challenge to administer. Figure 1 shows a typical organization, with an external Web server, a firewall + restricting access to the internal network, and internal databases and applications. +
++
+Figure 1
+ + With CGI and vendor APIs, the application has to run on the Web server machine. This means the server + administrator has to replicate the necessary database information onto the system hosting the Web server + (which may be difficult to do in an automated way without compromising firewall security). Or, the + administrator may build a "bridge" that allows access through the Web server to internal databases + and applications (which is effectively re-inventing remote FastCGI). +
++ With remote FastCGI, the applications can run on the internal network, simplifying the administrator's + job. When used with appropriate firewall configuration and auditing, this approach provides a secure, + high-performance, scalable way to bring internal applications and data to the external network. +
++ For resource-intensive CGI and API applications, the Web server machine quickly becomes the bottleneck for + overall throughput. The usual way to solve this performance problem is to buy a bigger, faster Web server + machine, or to partition the Web site across several Web servers. +
++ With remote FastCGI, the resource-intensive applications can be moved off the Web server machine, giving the + server administrator additional flexibility in configuring the Web server. The administrator can configure + FastCGI applications "behind the scenes" without having to change any content links or the external + view of the Web site. The administrator can use several smaller, inexpensive server machines for applications, + and can tailor each machine to the application it is hosting. +
++ The two security issues with remote FastCGI connections are authentication and privacy. FastCGI applications + should only accept connections from Web servers that they trust (the application library includes support for + IP address validation). Future versions of the protocol will include support for applications authenticating + Web servers, as well as support for running remote connections over secure transport protocols such as SSL or + PCT. +
++ This section offers a brief introduction to the protocol used on the connection between the Web server and + FastCGI application. Most application developers will use the FastCGI application library and won't have + to worry about the protocol details. However, specialized applications are free to implement the FastCGI + protocol directly. +
++ FastCGI uses a simple packet record format on the connection between the application and the Web server. The + same record format is used in both directions and is outlined in Figure 2. +
++
+
Figure 2
+ + The protocol version field specifies the version of the FastCGI protocol that is in use. The type field + specifies the type of the record (described in the following section). The request ID identifies this record + to a particular request, allowing multiple requests to be multiplexed over a single connection. The data + length field specifies the number of data bytes that follow. +
++ The different FastCGI packet types are: +
+| + FCGI_PARAMS + | ++ Used for sending name/value pairs (CGI environment variables) from the Web server to the application. + | +
| + FCGI_STDIN + | ++ Used for sending the standard input from the Web server to the application. + | +
| + FCGI_DATA + | ++ Used for sending filter data to the application (for more information, see the filter role described on + page 7.) + | +
| + FCGI_STDOUT + | ++ Used to send standard output from the application to the Web server. + | +
| + FCGI_STDERR + | ++ Used to send standard error information from the application to the Web server. + | +
| + FCGI_END_REQUEST + | ++ Ends the request (can be sent by either the server or the application). + | +
+
++ For complete protocol details, see the FastCGI Protocol Specification, available from the Web site + listed at the end of this paper. +
++ A major problem with CGI is its limited functionality: CGI programs can only provide simple responses to + requests. FastCGI provides expanded functionality with support for three different application + "roles": +
++ Other roles will be defined in the future. For instance, a "logger" role would be useful, where the + FastCGI program would receive the server's log entries for real-time processing and analysis. +
++ The roles are described in more detail in the following sections. +
++ FastCGI's Responder role is identical to the functionality provided by CGI today. When a request comes + into the server, the FastCGI program generates the response that's returned to the client (typically an + HTML page). +
++ The Filter role allows a FastCGI application to process a requested file before it is returned to the client. +
++ Let's assume that the Web server is configured so that all files with the .sgml + extension are processed by a SGML-to-HTML FastCGI filter application, and the user accesses the following URL: +
++ /document.sgml +
++ After the Web server makes an access control decision and maps this URL to a content file, it invokes the + FastCGI filter application with this file available as input. The FastCGI program's HTML output is sent + back to the client, just as in the responder role. The process is outlined in Figure 3. +
++
+
Figure 3
+ + Filter applications can significantly improve performance by caching filter results (the server provides the + modification time in the request information so that applications can flush the cache when the server file has + been modified). +
++ The Filter role is useful for: +
++ The Authorizer role allows a FastCGI application to make an access control decision for a request. The FastCGI + application is invoked with all of the request information, just as in the Responder role. If the authorizer + application generates a "200 OK" HTTP result, the Web server assumes that access is allowed and + proceeds with the request. (The Web server may process other access checks, including other FastCGI + authorizers, before access is ultimately allowed.) If the application generates any other response, that + response is returned to the client and the request is ended. The response can be any valid HTTP response, + including "Access Denied" or "Redirect". +
++ The Authorizer role is useful for: +
++ Open Market has developed a FastCGI application library that implements the FastCGI protocol (hiding the + protocol details from the developer). This library makes implementing FastCGI programs as easy as writing CGI + applications. +
++ The application library provides a replacement for the C language standard I/O (stdio) routines, such as printf() and gets(). The library converts references to standard input, + standard output, and standard error to the FastCGI protocol. References to other files "fall + through" to the underlying operating system standard I/O routines. +
++ This approach has several benefits: +
++ Here's a simple FastCGI application: +
++ #include <fcgi_stdio.h> - - - - - - -FastCGI - - - - - - - - - - - - - - - - -- -Open Market, Inc. - -
- -
Technical White - -Paper - -
- -FastCGI:
- - - -
- -A High-Performance Web Server Interface- -April 1996 - -
- - - -1. Introduction
- - - -- -The surge in the use of the Web by business has created - -a tremendous need for server extension applications that create - -dynamic content. These are the applications that will allow businesses - -to deliver products, services, and messages whose shape and content - -are in part determined by the interaction with, and knowledge - -of, the customers to which they are delivered. - -
- -This important movement away from static Web content - -is pushing the limits and exposing the weaknesses of the environment - -in which these applications are currently bound: CGI (Common Gateway - -Interface). Most importantly it does not offer the performance - -these applications require. A new communication infrastructure - -is needed to connect Web servers with these new applications. - -This is what led Open Market to develop FastCGI. - -
- -FastCGI is a fast, open, and secure Web server interface - -that solves the performance problems inherent in CGI, without - -introducing the overhead and complexity of proprietary APIs (Application - -Programming Interfaces). - -
- -This paper assumes that the reader has basic familiarity - -with Web technology and developing Web applications. - -
Common Gateway Interface
- - - -- -The de facto standard interface for Web server applications - -is CGI, which was first implemented in the NCSA server. CGI has - -many benefits: - -
- -CGI also has some significant drawbacks. The leading - -problem is performance: Since a new process is created for each - -request and thrown away when the request is done, efficiency is - -poor. - -
- -CGI also has limited functionality: It only supports - -a simple "responder" role, where the application generates - -the response that is returned to the client. CGI programs can't - -link into other stages of Web server request processing, such - -as authorization and logging. - -
- -In response to the performance problems for CGI, - -several vendors have developed APIs for their servers. The two - -most notable are NSAPI from Netscape and ISAPI from Microsoft. - - The freely available Apache server also has an API. - -
- -Applications linked into the server API may be significantly - -faster than CGI programs. The CGI startup/initialization problem - -is improved, because the application runs in the server process - -and is persistent across requests. Web server APIs also offer - -more functionality than CGI: you can write extensions that perform - -access control, get access to the server's log file, and link - -in to other stages in the server's request processing. - -
- -However, APIs sacrifice all of CGI's benefits. Vendor - -APIs have the following problems: - -
- -The FastCGI interface combines the best aspects of - -CGI and vendor APIs. Like CGI, FastCGI applications run in separate, - -isolated processes. FastCGI's advantages include: - -
- -The following sections describe the FastCGI interface, - -protocol, application library, and support in Open Market's WebServer - -products. - -
- -The functionality provided by the FastCGI interface - -is very similar to that provided by CGI. To best understand the - -FastCGI protocol, we review the CGI interface here. Basic CGI - -request processing proceeds as follows: - -
- -FastCGI is conceptually very similar to CGI, with - -two major differences: - -
- -Request processing in a single-threaded FastCGI application - -proceeds as follows: - -
- -FastCGI applications 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 to the FastCGI application - -process. For remote applications, the server uses a TCP connection. - -
- -FastCGI applications can be single-threaded or multi-threaded. - - For single threaded applications, the Web server maintains a - -pool of processes (if the application is running locally) to - -handle client requests. The size of the pool is user configurable. - - Multi-threaded FastCGI applications may accept multiple connections - -from the Web server and handle them simultaneously in a single - -process. (For example, Java's built-in multi-threading, garbage - -collection, synchronization primitives, and platform independence - -make it a natural implementation language for multi-threaded FastCGI - -applications.) - -
- -FastCGI's ability to run applications remotely (over - -a TCP connection) provides some major benefits. These benefits - -are described in this section, along with some of the security - -issues that affect remote FastCGI applications. - -
- -Applications that run on organizational (external) Web servers - -and depend on internal databases can be a challenge to administer. - -Figure 1 shows a typical organization, with an external Web server, - -a firewall restricting access to the internal network, and internal - -databases and applications. - -
- -
Figure
-
-1- -With CGI and vendor APIs, the application has to run on the Web - -server machine. This means the server administrator has to replicate - -the necessary database information onto the system hosting the - -Web server (which may be difficult to do in an automated way without - -compromising firewall security). Or, the administrator may build - -a "bridge" that allows access through the Web server - -to internal databases and applications (which is effectively re-inventing - -remote FastCGI). - -
- -With remote FastCGI, the applications can run on the internal - -network, simplifying the administrator's job. When used with - -appropriate firewall configuration and auditing, this approach - -provides a secure, high-performance, scalable way to bring internal - -applications and data to the external network. - -
- -For resource-intensive CGI and API applications, the Web server - -machine quickly becomes the bottleneck for overall throughput. - -The usual way to solve this performance problem is to buy a bigger, - -faster Web server machine, or to partition the Web site across - -several Web servers. - -
- -With remote FastCGI, the resource-intensive applications can be - -moved off the Web server machine, giving the server administrator - -additional flexibility in configuring the Web server. The administrator - -can configure FastCGI applications "behind the scenes" - -without having to change any content links or the external view - -of the Web site. The administrator can use several smaller, inexpensive - -server machines for applications, and can tailor each machine - -to the application it is hosting. - -
- -The two security issues with remote FastCGI connections are authentication - -and privacy. FastCGI applications should only accept connections - -from Web servers that they trust (the application library includes - -support for IP address validation). Future versions of the protocol - -will include support for applications authenticating Web servers, - -as well as support for running remote connections over secure - -transport protocols such as SSL or PCT. - - - -
- -This section offers a brief introduction to the protocol - -used on the connection between the Web server and FastCGI application. - - Most application developers will use the FastCGI application - -library and won't have to worry about the protocol details. However, - -specialized applications are free to implement the FastCGI protocol - -directly. - -
- -FastCGI uses a simple packet record format on the - -connection between the application and the Web server. The same - -record format is used in both directions and is outlined in Figure 2. - -
- -
Figure
-
-2- -The protocol version field specifies the version - -of the FastCGI protocol that is in use. The type field specifies - -the type of the record (described in the following section). - -The request ID identifies this record to a particular request, - -allowing multiple requests to be multiplexed over a single connection. - - The data length field specifies the number of data bytes that - -follow. - -
- -The different FastCGI packet types are: - -
| FCGI_PARAMS - - | Used for sending name/value pairs (CGI environment variables) from the Web server to the application. - - |
| FCGI_STDIN - - | Used for sending the standard input from the Web server to the application. - - |
| FCGI_DATA - - | Used for sending filter data to the application (for more information, see the filter role described on page 7.) - - |
| FCGI_STDOUT - - | Used to send standard output from the application to the Web server. - - |
| FCGI_STDERR - - | Used to send standard error information from the application to the Web server. - - |
| FCGI_END_REQUEST - - | Ends the request (can be sent by either the server or the application). - - |
- - - -
- -For complete protocol details, see the FastCGI Protocol Specification, - -available from the Web site listed at the end of this paper. - -
- -A major problem with CGI is its limited functionality: - - CGI programs can only provide simple responses to requests. - -FastCGI provides expanded functionality with support for three - -different application "roles": - -
- -Other roles will be defined in the future. For instance, - -a "logger" role would be useful, where the FastCGI program - -would receive the server's log entries for real-time processing - -and analysis. - -
- -The roles are described in more detail in the following - -sections. - -
- -FastCGI's Responder role is identical to the functionality - -provided by CGI today. When a request comes into the server, - -the FastCGI program generates the response that's returned to - -the client (typically an HTML page). - -
- -The Filter role allows a FastCGI application to process - -a requested file before it is returned to the client. - -
- -Let's assume that the Web server is configured so - -that all files with the .sgml - -extension are processed by a SGML-to-HTML - -FastCGI filter application, and the user accesses the following - -URL: - -
- - /document.sgml - -
- -After the Web server makes an access control decision - -and maps this URL to a content file, it invokes the FastCGI filter - -application with this file available as input. The FastCGI program's - -HTML output is sent back to the client, just as in the responder - -role. The process is outlined in Figure 3. - -
- -
Figure
-
-3- -Filter applications can significantly improve performance - -by caching filter results (the server provides the modification - -time in the request information so that applications can flush - -the cache when the server file has been modified). - -
- -The Filter role is useful for: - -
- -The Authorizer role allows a FastCGI application - -to make an access control decision for a request. The FastCGI - -application is invoked with all of the request information, just - -as in the Responder role. If the authorizer application generates - -a "200 OK" HTTP result, the Web server assumes that - -access is allowed and proceeds with the request. (The Web server - -may process other access checks, including other FastCGI authorizers, - -before access is ultimately allowed.) If the application generates - -any other response, that response is returned to the client and - -the request is ended. The response can be any valid HTTP response, - -including "Access Denied" or "Redirect". - -
- -The Authorizer role is useful for: - -
- -Open Market has developed a FastCGI application library - -that implements the FastCGI protocol (hiding the protocol details - -from the developer). This library makes implementing FastCGI programs - -as easy as writing CGI applications. - -
- -The application library provides a replacement for - -the C language standard I/O (stdio) routines, such as printf() - -and gets(). - - The library converts references to standard input, standard output, - -and standard error to the FastCGI protocol. References to other - -files "fall through" to the underlying operating system - -standard I/O routines. - -
- -This approach has several benefits: - -
- -Here's a simple FastCGI application:
-
- #include <fcgi_stdio.h>
-
- void main(void)
- {
- int count = 0;
- while(FCGI_Accept() >= 0) {
- printf("Content-type: text/html\r\n");
- printf("\r\n");
- printf("Hello world!<br>\r\n");
- printf("Request number %d.", count++);
- }
- exit(0);
- }
-
-This application returns a "Hello world"
-
-HTML response to the client. It also keeps a counter of the number
-
-of times it has been accessed, displaying the value of the counter
-
-at each request.
-
-- -The fcgi_stdio.h - -header file provides the FastCGI replacement routines for the - -C standard I/O library. The FCGI_Accept() - -routine accepts a new request from the Web server. - -
- -The application library was designed to make migration - -of existing CGI programs as simple as possible. Many applications - -can be converted by adding a loop around the main request processing - -code and recompiling with the FastCGI application library. FastCGI - -applications have the following structure, with an initialization - -section and a request processing loop:
-
-
-Initialize application;
-
-while(FCGI_Accept() >= 0) {
-
- Process request;
-
-}
-
-
- -To ease migration to FastCGI, executables built with - -the application library can run as either CGI or FastCGI programs, - -depending on how they are invoked. The library detects the execution - -environment and automatically selects FastCGI or regular I/O routines, - -as appropriate. - -
- -After migration, developers can clean up their FastCGI - -applications for best performance: - -
- -Applications written in Perl, Tcl, and other scripting - -languages can be migrated by using a language interpreter built - -with the application library. FastCGI-integrated Tcl and Perl - -interpreters for popular Unix platforms are available from Open - -Market. The interpreters are backward-compatible: They can run - -standard Tcl and Perl applications. - -
- -This section describes the FastCGI support in the - -following Open Market server products: - -
- -For more information about FastCGI support, see - -the Open Market WebServer Installation and Configuration Guide. - -
- -FastCGI applications are configured with the server's - -configuration file. Configuration has two parts. - -
- -First, the server administrator defines an application - -class. For local applications, the application class specifies - -the details of running the FastCGI application, such as: - -
- -For remote applications, the class configuration - -information includes the host and TCP port to connect to. The - -Web server assumes that the FastCGI application has been started - -on the remote host. If a request comes in and the server can't - -connect to the FastCGI TCP port, the server logs an error and - -returns an error page to the client. - -
- -The second configuration step is mapping the application - -class to a role: - -
- -To simplify migration for existing CGI programs, - -the WebServer provides a simple way to install new FastCGI programs - -without having to reconfigure the server. However, this approach - -doesn't offer all of the performance benefits of FastCGI application - -classes. - -
- -The WebServer treats any file with the extension - -.fcg as - -a FastCGI application. When a request corresponds to such a file, - -the WebServer creates a new FastCGI process to handle the request, - -and shuts down the process when the request is complete (just - -as in CGI). In this mode of operation performance is comparable - -to CGI. Future versions of the WebServer will improve performance - -by automatically caching processes and re-using them for subsequent - -requests. - -
- -FastCGI programs can improve performance by caching - -information in the application process. For applications that - -require frequent but expensive operations such as validating a - -username/password in an external database for each request, this - -technique can significantly improve performance. - -
- -To improve the effectiveness of this technique, the - -WebServer implements session affinity. When session affinity - -is enabled, the WebServer arranges for all requests in a user - -session to be handled by the same FastCGI application process. - - What constitutes a "session" is configurable. The - -default configuration uses the WebServer's built-in session tracking - -facility to identify user sessions. However, the server administrator - -can use any part of the request information for the session affinity - -mapping: the URL path, the client's hostname, the username, etc. - - - -
- -How fast is FastCGI? The answer depends on the application. - - This section contains some real FastCGI performance measurements, - -as well as guidelines for estimating the FastCGI speedup. - -
- -We measured the relative performance of CGI, FastCGI, - -and static files on the Open Market WebServer, using a simple - -application that generates a fixed number of output bytes. The - -following table shows the measured request processing time for - -different request types on a typical platform. The times are - -measured from the client perspective and include client, server, - -and application processing time. - -
- -FastCGI performance is comparable to serving static files, and - -significantly better than CGI (clearly showing the high overhead - -for process creation). Real applications have an additional time - -component: process initialization, which should be added to overall - -request processing time. - -
- -Let's use this data to estimate the speedup from migrating a typical - -database CGI application to FastCGI. Assume the application takes - -50ms to initialize the database connection and generates 5K of - -output data. Request performance can be computed as follows: - -
| CGI | 59ms + 50ms + (0.37ms)(5) = 111ms - - |
| FastCGI | 22ms + (0.28ms)(5) = 23ms - - |
- -In this example, FastCGI has a 5x performance advantage over CGI, - -mostly due to savings from not having to create and initialize - -new processes for each request. - - - -
- -Today's Web business applications need a platform - -that's fast, open, maintainable, straightforward, stable, and - -secure. FastCGI's design meets these requirements, and provides - -for a logical extension from proven and widely deployed CGI technology. - - This allows developers to take advantage of FastCGI's benefits - -without losing their existing investment in CGI applications. - - - -
- -For more information about Open Market and our products, - -visit our Web site at:http://www.openmarket.com/ - -
- -For more information about the FastCGI protocol and - -the developer's kit, and the latest information about FastCGI - -standardization and support in other Web servers, visit the FastCGI - -project page at:http://www.openmarket.com/fastcgi/ - - - - - + void main(void) + { + int count = 0; + while(FCGI_Accept() >= 0) { + printf("Content-type: text/html\r\n"); + printf("\r\n"); + printf("Hello world!<br>\r\n"); + printf("Request number %d.", count++); + } + exit(0); + } + +
+ This application returns a "Hello world" HTML response to the client. It also keeps a counter of the + number of times it has been accessed, displaying the value of the counter at each request. +
++ The fcgi_stdio.h header file provides the FastCGI replacement routines for the C standard I/O + library. The FCGI_Accept() routine accepts a new request from the Web server. +
++ The application library was designed to make migration of existing CGI programs as simple as possible. Many + applications can be converted by adding a loop around the main request processing code and recompiling with + the FastCGI application library. FastCGI applications have the following structure, with an initialization + section and a request processing loop: +
+
+ Initialize application;
+ while(FCGI_Accept() >= 0) {
+ Process request;
+ }
+
+ To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI + programs, depending on how they are invoked. The library detects the execution environment and automatically + selects FastCGI or regular I/O routines, as appropriate. +
++ After migration, developers can clean up their FastCGI applications for best performance: +
++ Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language + interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix + platforms are available from Open Market. The interpreters are backward-compatible: They can run standard Tcl + and Perl applications. +
++ This section describes the FastCGI support in the following Open Market server products: +
++ For more information about FastCGI support, see the Open Market WebServer Installation and Configuration + Guide. +
++ FastCGI applications are configured with the server's configuration file. Configuration has two parts. +
++ First, the server administrator defines an application class. For local applications, the application + class specifies the details of running the FastCGI application, such as: +
++ For remote applications, the class configuration information includes the host and TCP port to connect to. The + Web server assumes that the FastCGI application has been started on the remote host. If a request comes in and + the server can't connect to the FastCGI TCP port, the server logs an error and returns an error page to + the client. +
++ The second configuration step is mapping the application class to a role: +
++ To simplify migration for existing CGI programs, the WebServer provides a simple way to install new FastCGI + programs without having to reconfigure the server. However, this approach doesn't offer all of the + performance benefits of FastCGI application classes. +
++ The WebServer treats any file with the extension .fcg as a FastCGI application. When a + request corresponds to such a file, the WebServer creates a new FastCGI process to handle the request, and + shuts down the process when the request is complete (just as in CGI). In this mode of operation performance is + comparable to CGI. Future versions of the WebServer will improve performance by automatically caching + processes and re-using them for subsequent requests. +
++ FastCGI programs can improve performance by caching information in the application process. For applications + that require frequent but expensive operations such as validating a username/password in an external database + for each request, this technique can significantly improve performance. +
++ To improve the effectiveness of this technique, the WebServer implements session affinity. When session + affinity is enabled, the WebServer arranges for all requests in a user session to be handled by the same + FastCGI application process. What constitutes a "session" is configurable. The default configuration + uses the WebServer's built-in session tracking facility to identify user sessions. However, the server + administrator can use any part of the request information for the session affinity mapping: the URL path, the + client's hostname, the username, etc. + +
++ How fast is FastCGI? The answer depends on the application. This section contains some real FastCGI + performance measurements, as well as guidelines for estimating the FastCGI speedup. +
++ We measured the relative performance of CGI, FastCGI, and static files on the Open Market WebServer, using a + simple application that generates a fixed number of output bytes. The following table shows the measured + request processing time for different request types on a typical platform. The times are measured from the + client perspective and include client, server, and application processing time. +
+|
+
+ Static file
+
+ |
+
+
+ 21ms + 0.19ms per Kbyte
+
+ |
+
|
+
+ FastCGI
+
+ |
+
+
+ 22ms + 0.28ms per Kbyte
+
+ |
+
|
+
+ CGI
+
+ |
+
+
+ 59ms + 0.37ms per Kbyte
+
+ |
+
+ FastCGI performance is comparable to serving static files, and significantly better than CGI (clearly showing + the high overhead for process creation). Real applications have an additional time component: process + initialization, which should be added to overall request processing time. +
++ Let's use this data to estimate the speedup from migrating a typical database CGI application to FastCGI. + Assume the application takes 50ms to initialize the database connection and generates 5K of output data. + Request performance can be computed as follows: +
+| + CGI + | ++ 59ms + 50ms + (0.37ms)(5) = 111ms + | +
| + FastCGI + | ++ 22ms + (0.28ms)(5) = 23ms + | +
+ In this example, FastCGI has a 5x performance advantage over CGI, mostly due to savings from not having to + create and initialize new processes for each request. +
++ Today's Web business applications need a platform that's fast, open, maintainable, straightforward, + stable, and secure. FastCGI's design meets these requirements, and provides for a logical extension from + proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's benefits + without losing their existing investment in CGI applications. + + +
++ For more information about Open Market and our products, visit our Web site at:http://www.openmarket.com/ +
++ For more information about the FastCGI protocol and the developer's kit, and the latest information about + FastCGI standardization and support in other Web servers, visit the FastCGI project page at:http://www.openmarket.com/fastcgi/ +
+