Microsoft FastCGI Updated – But Should You Upgrade?

We previously covered the final release of the IIS FastCGI module, jointly developed between Microsoft and Zend… But just this week, Microsoft [[MSFT]] announced the availability of the RTM of the IIS FastCGI module.

So what’s going on? We’ve downloaded the current release (which, by the way, is not compatible with the old one, you must uninstall then install the new version) and checked the version number on \Windows\System32\inetsrv\fcgiext.dll – it came out to be 6.1.36.1.

By contrast, the version we downloaded and installed a month ago (which seems to have been dubbed the Go Live release) was checked and found to be 7.0.6001.16606.

Obviously the Go Live release was using the numbering from the Microsoft Windows Server 2008 releases, but it’s got us confused.

You can find a timeline of the FastCGI module’s development and milestone cycle  Mike Volodarsky (Microsoft IIS developer)’s blog – but it makes no mention whatsoever of the October 10th 2007 release.

What has most perplexed isn’t the lack of a complete release schedule nor the conflicting version numbers – those are easy. As with most other applications, the latest is greatest – end of story. For us, the problem is that the RTM FastCGI module is less stable than the Go Live release from last month. This is real bad new, because the FastCGI module has been awesome and most invaluable tool when it comes to deploying certain buggy open-source modules on Windows.

Our experience with the RTM FastCGI module has not been all bad – performance has been slightly (as in < 1 req/seq) improved. But upgrading is a PITA and the RTM module wouldn’t abide by the configuration file the first time we installed it – to the extent that it served our PHP files as plain-text, a HUGE security no-no. But then we deleted the configuration file and started from scratch and everything was OK…

But then the FastCGI processes started to balk and quit, requests were timing out too fast (despite using the same configuration file directives), and rapid-fail protection was being engaged far too often.

It seems that the timeout syntax has reverted to the original semantics of the earlier releases prior to the Tech Previews, where the ActivityTimeout will kick in even the RequestTimeout hasn’t yet been reached…. But we’re not certain.

At the moment our problems seem to have been sorted out (by raising all the limits in our configuration file by a lot) but, of course, everything has its price. We’re hoping that raising the timeouts won’t induce and instability or end up with FastCGI module unable to detect a hanged process – but only time will tell.

In the meantime, if you’re running the October 2007 release (which, by the way, we cannot seem to locate any more) you should probably hold off upgrading for a week or two until things get sorted out.