FastCGI Resurgence

I must confess at being rather puzzled that FastCGI is getting so much attention lately. I remember coming across it in the ’90s during my PhD — the inefficiency of CGI was an issue then as it is now — but then trends appeared to be leaving FastCGI behind. Either you integrated the application framework with apache using mod_php/perl/python or you used a specialised application server such as Zope, putting it behind an apache proxy if necessary. I chose the former when developing the MCM website and for a time I did battle with Zope’s many complex features. What has changed now to bring FastCGI to the fore?

I should have had an inkling of the reason from an experience I had a year or so ago whilst developing an application for the Climateprediction.net project. I chose to use mod_python but their site used the mod_php. It transpired that when using the distro.’s packages these two modules didn’t sit well together. They both tried to link to different versions of libxml and uggly core dumps followed. I fixed it by recompiling mod_php but it was hardly a solution one would want to repeat.

Bryan Lawrence has brought together some insightful wisdom on the matter here and here. I’m embarassed to admit it’s taken me so long to read them. Also the Wikipedia entry for FastCGI explain’s it’s resugrence. In a world of a million and one web frameworks it isn’t feasible to re-implement a webserver for each one, let alone squeeze them all into one server process with mod_*.

It all helps to reassure me that my instincts were right when I began to go cold on Zope. It is a great platform to work with once you know how but it’s great weakness is that it reinvents everything at once: object publisher, templates, authentication, permissions, the lot. It makes for an enormous learning curve and then people build more complexity on top with Plone and the like. It’s just not very agile.