FastCGI is an extension of CGI which eliminates CGI drawbacks and provides high performance, while remaining highly compatible with the existing CGI applications. See the page http://www.fastcgi.com/kit/doc/fastcgi-whitepaper/fastcgi.htm for a more detailed overview of FastCGI.

The simple answer is that it was becoming too difficult to keep the version being included with Apache synchronized with the master copy at the FastCGI web site. When a new version of Apache was released, the version of the FastCGI module included with it would soon be out of date.

use FCGI; my $request = FCGI::Request(); while ( $request->Accept() >= 0 ) { $cgi->dispatch(); }

Starting from version 2.3, Abyss Web Server features support for applications and interpreters conforming to the FastCGI specification. A FastCGI application or interpreter is loaded when needed by the web server, it executes a script, and sends its output back to the server. But instead of having its process automatically unloaded from the system as with CGI, it remains in sleeping state waiting for another request from the web server.

FastCGI interpreters and applications deliver performances comparable to (if not better than) their ISAPI extensions counterparts. Because they run in another process, they cannot affect the server and crash it if they have problems. This makes their use not prone to stability problems ISAPI extensions may cause.

In the Default Website, under ISAPI filters, create a new filter in addition to the PHP one. Call it fastcgi and point it to isapi_fcgi.dll. Under the Home Directory tab, select Configuration and, change the .php extension to use isapi_fcgi.dll. Q: ERROR: change root is not supported by your OS or at least by this copy of rrdtool. This error message occurs when you use the Win32 version of rrdtool instead of the Cygwin one. RRDTool 1.2.15 and later work with the Win32 build.

If you buy FastCGI software, you are probably paying for support, so you should follow your software vendor's support procedures. If you use free FastCGI software, you can't expect formal support. But there is an active FastCGI mailing list where you can ask questions, report problems, and make suggestions. The FastCGI mail page provides instructions for adding yourself to and removing yourself from the mailing list.

To illustrate the issues in porting CGI apps to FastCGI we'll port a Perl script that does the following: This is not a serious application but it does highlight many porting issues.

Since FastCGI applications are started from the Web server and are run dissociated from a controlling terminal, some of the debugging techniques you are used to won't work. But there are replacements. If you are accustomed to using an interactive debugger such as gdb or dbx, you can still use these debuggers on FastCGI apps. As usual, you must compile the app for debugging (e.g. -g switch to gcc) in order to get the best use of the debugger.

We'll demonstrate how to configure a distributed FastCGI app using our Perl script that reports and logs the information from the uptime command. The idea is to run the Perl script on one machine and access the script from another machine. With FastCGI, no changes to the script are needed to make it remotely accessible. We can start and access the program using different modes of the cgi-fcgi utility. Assume that cgi-fcgi is located in directory $PATH, the Perl script is named uptime.

Yes, thanks to the FCGI module. Assign the script the .fcgi extension (or you could also map the fastcgi-script type using an .htaccess file). FastCGI scripts execute setuid so you can use a permission mode such as 0700 on the file.

First of all, mod_fastcgi spawns an application called "fcgi-pm" (FastCGI Process Manager), it in turn spawns the persistent FastCGI enabled application. Fcgi-pm pipes information back and forth between Apache and the FastCGI enabled application. This way, only one running process is needed to execute PHP scripts, where previously we needed one CGI application running for each script that was processing.

To make Gantry::Conf work, you must tell it which instance you need to configure. In CGI and FastCGI do this by setting this by setting this key in the config hash passed to the Gantry::Engine::CGI constructor: If you are not using the default /etc/gantry.conf for Gantry::Conf's configuration, set one additional variable:

The FastCGI servers page lists all the server modules that are currently available. An additional server module, the cgi-fcgi program, runs on any Web server that supports CGI and is included in the FastCGI developer's kit.

Yes. All CGI and FastCGI applications (including PHP scripts) will execute with your own unix account privileges. To save on resources, many inexpensive shared hosting providers will execute PHP scripts under a single account shared by all users of the system (thus requiring users to open up their script data and databases to unauthorized access and intellectual property theft by other users on the same system). On our systems, all web applications will execute under your own unix privileges.