Смекни!
smekni.com

My Dying Bride Essay Research Paper Performance (стр. 1 из 2)

My Dying Bride Essay, Research Paper

Performance Enhancement

FastCGI API

What a FastCGI Application Looks Like

FastCGI and C

FastCGI with Perl and Tcl

Installing and Configuring FastCGI

Incorporating FastCGI Functionality into Apache

cgi-fcgi

Building the FastCGI Developer’s Kit

Making Perl Fly

Perl FastCGI Programs

The mod_fastcgi Module

The AppClass Directive

Example

Summary

C

FastCGI

FastCGI is a high-performance replacement to the CGI standard. It provides a significant improvement in performance over the existing CGI interface. In its current implementation, FastCGI provides many

desirable enhancements that make it a very attractive and competitive alternative to proprietary technologies for developing Web-based applications. Under many circumstances, it will be a better choice to

implement FastCGI than to develop a custom server module using Apache’s proprietary server Application Programmer’s Interface (API).

FastCGI is available from http://www.fastcgi.com. (See Figure C.1.) The site is the official resource to all FastCGI information. It has complete documentation and whitepapers on

FastCGI. Also nice is a mailing list?a threaded archive that is available through the Web.

Figure C.1. The FastCGI home page.

FastCGI is a proposed open standard; this means that it is not currently widely accepted, but it has received a warm welcome by many significant people on the Internet who are responsible for setting the

standards. More than likely, this welcome will turn into acceptance on both free and commercial Web server offerings, which will help it in becoming “blessed” from a standard point of view.

FastCGI is appealing not only because of its performance enhancements but because the effort required to migrate existing code is very small. As a bonus, software developed under this proposed standard

has a high degree of portability. These portability issues help a great deal toward setting it as a viable candidate to become a standard, especially on installations that have committed extensive resources to

CGI development.

FastCGI is not a development environment in terms of having to learn yet another programming language. In a very simplistic description, FastCGI it is a CGI program that uses additional libraries, so it does

require that you learn an API. The basic API is tiny, though; one call is all you need to migrate many of your current programs.

FastCGI Features

The main features of FastCGI are as follows:

A huge increase in performance. FastCGI programs continue to live between requests, making their responsiveness faster and reducing delays due to forking and program initialization.

Programming language-independent implementation. Like CGI, you can develop your FastCGI application with a variety of languages. Currently there are programming libraries for Perl, C/C++, Tcl,

and Java. Porting existing code to FastCGI is easy, allowing you to easily migrate your existing code base without having to redo what you have done.

FastCGI processes are isolated from the Web server core. Much like CGI, FastCGI applications offer greater security and reliability than developing a similar functionality as a module using a server

API.

Server technology separation. There are FastCGI modules for various servers, including Apache, NCSA, and the Open Market Secure WebServer. For any other server that supports CGIs, the

cgi-fcgi program, included in the FastCGI distribution, implements the FastCGI environment.

Distributed computing support. FastCGI applications can execute on a different host from the Web server. This allows you to offload FastCGI execution to other application servers, permitting your

Web server to handle an increased load. FastCGI programs can run on any host that can be reached over TCP/IP.

The concept of roles. Traditional CGI programs fall into the responder role; they respond to some action initiated by a browser and send back some HTML. FastCGI programs can also perform other

roles, such as a filter or as part of some authentication scheme. This allows for providing extra functionality that would usually be relegated to a server module. The currently available FastCGI module

for Apache does not include support for roles other than responder, but this may change in the future.

Performance Enhancement

The increase in performance alone would be a good enough reason to migrate CGIs to FastCGI, especially on loaded servers. This increase in performance is achieved primarily because FastCGI processes

are persistent. Forking under UNIX is very expensive, and FastCGI addresses this issue by reusing processes. This saves on the initialization time and can also provide enhancements when data calculated by

one call to the program can be reused in another transaction.

Unlike CGIs, which are forked every time there’s a request for the functionality, FastCGI processes are reused. After a request is fulfilled, the process remains, waiting for additional requests.

Programs that rely on an interpreter such as Perl or Tcl can gain a great deal from this technology because the command interpreter will compile the program once, not once per call. The time required to do

all this pre-run initialization is eliminated. On the program side, this can yield to enhancements such as establishing a connection with a database or some other process because the connection only needs to

happen once. Add to this the load to launch the interpreter program, and the savings are significant.

What sort of performance gains can you obtain? According to information posted on the FastCGI Web site, Open Market’s tests show the following:

Request

Client, Server, and Application Processing Time

Static File

21ms + 0.19ms/KB

FastCGI

22ms + 0.28ms/KB

CGI

59ms + 0.37ms/KB

Add to this the cumulative time that it takes for an application to establish a TCP/IP connection to, say, a database. Under CGI, a process will have to initialize each time it is run. FastCGI can yield a

performance increase of four times the speed of the same program used as CGI. In load terms, this could mean that your server could potentially handle four times your current CGI load. However, the level

of enhancement will depend on the source of the bottleneck. If your database server is the current source of the problem, FastCGI cannot do much about that except reduce the number of connections that

the database server will need to perform, perhaps giving it more time to process data instead.

FastCGI API

The FastCGI API has a handful of calls:

FCGI_Accept is used to implement the server connectivity and control the running of the FastCGI program.

FCGI_Finish gives you control after the FastCGI program has executed, but before running the next request.

FCGI_SetExitStatus is used to set the exit status of the request. Most CGI programs don’t return meaningful exit status, so this call is seldom used.

FCGI_StartFileterData enables you to implement a special type of FastCGI application, called a filter. Currently the Apache implementation of the FastCGI module doesn’t support roles, of which the

filter type is a member, but this likely will change in the near future. Filters allow you to implement programs that will convert one data format to another on-the-fly (for example, TIFF to GIF).

Data is read and written through the standard input, output, and error streams. FastCGI also provides macros that map files and streams to native calls supported by your operating system.

Like CGI, you can create FastCGI applications in almost any language. However, you are currently limited to the ports of the library. Currently available are Perl, C/C++, Tcl, Java, and very soon Python,

which should be available by the time you read this. Also in the works is a multithreaded C/C++ library that has not been released, but should be available as part of the 1.6 release. The multithreaded library

allows a single application process to handle concurrent requests, which will allow you to implement things like HTTP-based chat applications.

Even though FastCGI is not universal, most developers should find themselves at home in one of the programming languages previously mentioned. As soon as FastCGI gains more acceptance, there will be

additional libraries implemented. Developers are encouraged to port the FastCGI libraries to their programming language of choice, ensuring that the openness of the extension is more widely supported. The

success of FastCGI will depend on getting many vendors and programmers to support it. Given its current feature set, it should have no trouble reaching this goal.

The design of FastCGI also wins big on the learning curve because unlike server APIs, you are still programming a CGI, so you can leverage what you already know. The only issues that you will need to

address have to do with reorganizing your application so that the initialization code, which is done once, is kept separate from the application body. FastCGI applications are long-lived; they are kept alive

between transactions. This also means that memory needs to be managed because unlike CGIs, which have a short life span, FastCGI processes may execute for undetermined amounts of time.

Data sent to a FastCGI application by the server is accessed through special streams that provide complete binary compatibility with the CGI standard. This also allows a FastCGI program to run as a regular

CGI program. A FastCGI program can determine, at runtime, if it is being run as CGI or as FastCGI and behave accordingly.

This translates into an environment that allows you to migrate FastCGI programs down, should you ever need to. This provides server independence because the same binary can be run on two servers?say

Apache and Netscape?under the same operating system without even needing to be rebuilt or require programming modifications, even if the server couldn’t support FastCGI. This feature alone is very

interesting from a legacy and recycling standpoint. Also, all servers support FastCGI. The FastCGI Developer’s Kit comes with a program called cgi-fcgi that allows you to run FastCGI responder

applications. The cgi-fcgi program allows any Web server that supports CGI to run FastCGI.

FastCGI applications communicate with Apache using a single full-duplex connection. Through this connection, the server transmits the environment variables and stdin to the FastCGI application; stdout and

stderr streams from the application are sent back to the server.

What a FastCGI Application Looks Like

A modified version of my HelloWorld.c looks like this:

#include “fcgi_stdio.h”

#include *stdio.h*

int main (void)

{

int timesVisited = 0;

while(FCGI_Accept() *=0)

{

printf (”Content-type: text/html\r\n\r\n”);

printf(”*HTML*”);

printf(”*HEAD**TITLE*Hello World!*/TITLE**/HEAD*”);

printf(”*BODY**H1*Hello, this is a FastCGI program!*/H1*”);

printf(”*BIG**P*I can tell that you are visiting from %s.*/P*”);

printf(”*p*This page has been accessed: %d times*/P**/BIG**/BODY*”, getenv(”REMOTE_HOST”), ++timesVisited);

printf(”*/HTML*”);

}

}

This version makes use of the fact that the application is persistent and will maintain a count of the times the program is run (until the program dies).

As you can see from this example, FastCGI applications follow this sequence:

1.Initialization. Persistent connections or data that should be available from request to request are initialized in this section. Initialization is done only once. The initial environment for FastCGI applications

is set through the AppClass directive, which is added by the FastCGI module.

2.The Response Loop. This loop is started by the FCGI_Accept() routine, implemented in the FastCGI library. A call to this routine blocks program execution until the program receives a client request.

When it receives one, the routine unblocks, sets up an environment for the program, and runs one loop through the body. This routine is also responsible for determining the context under which the

program is running (FastCGI or CGI) and sets the environment accordingly.

3.Body. This portion of the program gets executed by each request. This is the meat of your program. Each request will have its own environment variables, just as in a regular CGI.

4.End of Response. A subsequent call to FCGI_Accept informs the server that the program has completed a request and is ready for another. FCGI_Accept once more blocks execution until the next

request.

This process is repeated until the FastCGI application is killed by the System administrator or the Web server. If the process were to die, the FastCGI module or cgi-fcgi program in the Web server is

responsible for making a FastCGI process available to handle the request. This means that if it dies, the server will fork another process to replace the original.

FastCGI and C

FastCGI implements two libraries: fcgi_stdio and fcgiapp. Both of these libraries are provided for building C applications utilizing the FastCGI toolkit.

The fcgi_stdio library implements stdio-compatible functionality and can be used for developing or porting existing C CGI applications. This library provides full binary compatibility between FastCGI and CGI

programs.

fcgiapp provides additional functionality to FastCGI applications at the expense of losing the CGI compatibility. There’s also an increase in the knowledge required to develop the application.

FastCGI with Perl and Tcl

You can run Perl- and Tcl-interpreted programs under FastCGI. In order to run them, you’ll have to compile a specially modified version of the interpreter that has been modified to work with FastCGI. You

will not, however, need to maintain both a regular and a special version of the interpreter. The special version will work as expected when used under a normal context. Future versions of Perl and Tcl will

incorporate changes that will make it possible to use unmodified versions of the program with FastCGI.

Patches for both Perl and Tcl are available. Some prebuilt binaries are also available at http://www.fastcgi.com.

Installing and Configuring FastCGI

To build and run FastCGI applications, you’ll need to have two different pieces of software: the FastCGI module for Apache and the FastCGI Developer’s Kit.

Both the toolkit and the Apache module are included in the CD-ROM that accompanies this book; however, you should make sure that they are still current. At the time of this writing, the Apache module

was still based on a beta version of 1.1. The latest and greatest versions of the module and developer’s kit are available at the FastCGI Web sites: http://www.fastcgi.com/servers and

http://www.fastcgi.com/applibs, respectively. The version of the toolkit included on the CD-ROM is 1.5.

Incorporating FastCGI Functionality into Apache

To add the FastCGI module to Apache is simple. Copy apache-fastcgi/src/mod_fastcgi.c to the Apache source directory (/usr/local/etc/httpd/src). Then you need to add an entry for the module in Apache’s

src/Configuration file. Add the following line at the end of the Module listings:

Module fastcgi_module mod_fastcgi.o

You’ll need to run Apache’s configuration program, src/Configure, and rebuild the Apache by issuing a make command while focused on the Apache src directory.

While Apache builds, you can add the following configuration directives to your servers conf/srm.conf configuration file:

AddType application/x-httpd-fcgi .fcgi

Alias /fcgi-bin/ /usr/local/etc/httpd/fcgi-bin

# AppClass

Create the fcgi-bin directory, while in /usr/local/etc/httpd:

% mkdir fcgi-bin

As you may be able to guess by now, FastCGI applications should be run from a directory other than the cgi-bin directory.

After Apache builds, issue the following commands:

% cd /usr/local/etc/httpd

% mv httpd httpd.prev

% mv src/httpd .

% strip httpd

% kill -HUP ‘cat /usr/local/etc/httpd/logs/httpd.pid`

This will restart the server and force rereading of the new configuration directives you just added. Watch for any error messages. If you get an error, more than likely one of the directives you added is

incorrect.

If the restart of the server proceeded without problems, congratulations?your sever is now ready to run FastCGI programs.

cgi-fcgi

An alternative way of implementing FastCGI on Apache, or any other server, is to use the cgi-fcgi program. cgi-fcgi is a standard CGI program that uses TCP/IP sockets to communicate with FastCGI

applications. cgi-fcgi takes the pathname or host/port name as a parameter and connects to the FastCGI application listening on that TCP port. cgi-fcgi then forwards the environment variables and stdin to the

FastCGI application and returns to the server the stdout and stderr streams. When the FastCGI application ends the connection, cgi-fcgi flushes and exits.

Although this is not as efficient as a module imbedded into the server because the cgi-fcgi program gets forked with every request, it is much better than not having it. For example, if your Perl FastCGI