CGI on steroids with FastCGI, but on a CGI-only server - The FastCGI wrapper

FastCGI is really CGI on steroids

FastCGI is very common way to increase performance of a CGI installation. It is based on the fact that usually the startup of CGI scripts is slow, whereas the response is quite fast.

So if you have a persistent process, you only have to take care of the startup once, and you then experience a real speedup.

FastCGI vs mod_perl (or mod_python, ...)

Once a big fan of mod_perl, I'm converted to FastCGI since. mod_perl was for a long time the answer for speeding up Perl CGI scripts. It has a very good track record of stability and has real hooks deep in the Apache processing requests.

FastCGI focuses on a different feature set that is more actual than mod_perl^[1] :

It is much simpler to install and configure, especially when having multiple applications.
Able to connect to a distant server (running as a different UID, chrooted or even on a remote host)
Able to mix scripting languages without any need to compile some other apache modules.
Able to be used with several webservers, even closed-source ones : FastCGI is a protocol, not an API.

But steroids do have some side effects

CGI issues

One downside is that your CGI script should be adapted to FastCGI and the fact that the script doesn't end with the end of the request.

In the real world that's quite easy. Every language that is commonly used for CGI offers CGI-wrapper libraries that works in a FastCGI context as well as a plain CGI one.

Webserver issues

Another issue can also come from the webserver. Since CGI is dead simple to implement even the micro-webserver thttpd implements it.

FastCGI on the other hand is a little more difficult to implement, since the webserver needs to create a container that monitors and calls the FastCGI-enabled script.

A standalone FastCGI container

Fortunately, the FastCGI team provided us with a ready-to-use container and a very simple client that acts a plain CGI script, but proxies it to a full-blown container.

Since the plain CGI part is a very small native executable its overhead is negligible compared to the reply time, even without comparison with the startup time of the whole script.

Its installation is also quite straightforward. I just installed the libfcgi package on Debian : it provides /usr/bin/cgi-fcgi.

I created a simple CGI wrapper for my previous munin benchmarking needs :

#! /bin/sh

exec /usr/bin/cgi-fcgi -connect /tmp/munin-cgi.sock \
     /usr/lib/cgi-bin/munin-cgi-graph

Notes

[1] who really need deep apache hooks ?

Comments

1. On Sunday, 1 May 2011, 21:02 by Mike Robinson

To me, the overwhelming advantage of FastCGI vs. mod_perl comes when the "web pages" on a site begin to vary from trivial, fast-running ones, to reports that might take hundreds of megabytes and hundreds of wall-clock seconds to complete. Suddenly, "an 'httpd' process instance" has ballooned from being a lean-and-mean process, in the eyes of the operating system, to a sluggish thousand-pound gorilla. Operating systems react slowly and awkwardly and inefficiently to such radical changes that come without warning. (They also recover poorly, when the "thousand pound gorilla" that it moved heaven-and-hell to accommodate, suddenly becomes a docile mouse again ... and then, oh my, ANOTHER 'httpd' instance has just turned into a gorilla!)

"Be nice to the operating system, and it will be nice to you." If not (and if you happen to remember this old TV commercial...) "it's not NICE to fool with Mother Nature..." The OS will accommodate you, because that's its job, but you will pay a price.

FastCGI moves the actual processing-work an arm's length away from the 'httpd' processes, allowing 'httpd' to continue to be fast-and-light at all times, and to continually present consistent run-time characteristics no matter what.

Depending on the FastCGI container (application server...) that you use (or build...), you can distribute the requests that the web-server is sending, among a "suitable" mixture of CPUs and service-processes. If you want to build queues, to use batch-processing software and so on, that also is much easier to do with the FastCGI way of doing things.

In short, 'httpd' is now able to remain as what it is best at being: a user-interface of sorts, able to field thousands of requests per second, but no longer -itself- burdened by the responsibility of actually servicing those requests. "It's just the delivery boy." Meanwhile, the FastCGI stream is serviced by a -team- of more-or-less specialist processes that may be running on any number of back-end computers. The results are predictable, debuggable, and scalable.

Personal Workflow Blog