FastCGI SA - Background

An updated version of Tim Armbruster's (TFA) patch for FastCGI to provide Session Affinity.

Session Affinity (SA)

SA allows a client (browser) to be pinned to a specific running instance of a persistant CGI program. TFA's pages on SA are very good and you should read them first. In essence it allows any CGI program to behave like a Servlet. Current Servlets are thought of as primarily a Java phenomenon. Here I am generalizing the term to mean a server-side program that keeps running between client access. In a more sophisticated form it is a program that can multiplex or thread allowing access by more than one client at a time. But either way it has one key difference, it is a program that can both remember what clients are doing or asking for and it can perform work between requests. This whole concept hinges on both the process instance persisting as well as a particular client's requests being consistenlty driven to the same instance. Without this combination an architecture needs to rely on databases, files or shared memory to achieve an approximation. Even with that, processing between hits is a tricky business.

Why use it?

FastCGI with SA makes this and a few other very nice features work. It allows a CGI program to continue as a process for a period of time longer than one hit. It also pins a client to a specific process. There are a few things to take note of here first. These long running CGI processes do not have to run indefinately, they can decide to exit, although this creates some interesting complexities. Client to instance pinning is accomplished by use if IP addresses or Cookies, both of which have potential pifalls. These pitfalls befall all Servlets, so FastCGI-SA is not unique in this respect. You also have to take a bit more care of memory in these CGIs because leaks will become apparent and make trouble.

There is another really big bonus with FastCGI. It gets your programs out of your web server and it is supported by a wide range of languages. Many of these languages do not have in-server modules or they do not belong there. So it facilitates both compartmentalization as well as language flexibility. If you have ever rebuilt Apache just to get another module in there, or had a bit of perspiration because you had to plug some more DSOs into your production server, this is a big plus. If your CGI program throws a rod (SEGV) or starts running out of control, it is a lot easier to debug and control when it is an isolated process. I have yet to come across a really good way of debugging modules in Apache. There may be one, but I have not found it yet.

There are some more useful features in FastCGI that are useful and pretty neat, but please look to the FastCGI site for more on that.

Why not?

To be fair (mostly to you), in this age of rather complete and fast server-side scripting like PHP, the case for FastCGI is not what it used to be. The likes of PHP are very fast especially when compared with the old style of 1-hit CGI programs. FastCGI is also more complex because it involves external processes and added configuration. It is also a real CGI framework and if you are used to having PHP set you up and clean up after you, then this is going to take a bit more effort. Most languages have a CGI library that deals with all of it, but it requires a bit more effort.

If you do not need SA, do not care what language your web application is written in, and are not writing things that will be a challenge to debug, then you may want to consider PHP first. There are other languages that you can embed in your web server, but I cannot make any general recommendations on that topic.

Caveats

I have adapted (and adopted) this patch from TFA's original so that it works with the current (2.4.0) version of FastCGI running under Apache 1.3.27. I have tested it on Solaris 7 and OS X 10.2.4. It has not been tested with Apache 2 nor Win32.

Credits

I want to thank Tim Armbruster for having written this patch to begin with.

Contributions (not money)

If you find something wrong, be it a bug or a questionable method, please contact me. I am on the FastCGI mailling list, but I suggest you  mail me directly at: danj at 3skel.com.

Configuration

You will want to read the FastCGI and TFA's pages on configuration.

This page last modified: