Congratulations are in order for Microsoft’s IIS development team – today they’ve just announced the public availability of the final version of the IIS-FastCGI ISAPI Extension – a long-awaited and much-improved way of running just about any open-source scripting engine on IIS, safely and quickly.
The Microsoft [[MSFT]] FastCGI module for IIS 5.1, 6, and 7 (with Windows Vista and Server 2008) have been in the works for quite a while now, and we’ve been using them since the first beta release – they’re good. While the biggest benefit will be seen in using FastCGI w/ IIS7 to take advantage of the new kernel-mode caching, it’s still a huge improvement over the old way of running scripting engines for languages like PHP on Windows.
The Problem: Most open-source scripting engines like PHP and Ruby on Rails were initially developed on/for the *nix world. On Unix-based platforms, the easiest way of creating multi-threaded applications is just to run the same app twice or more (The CGI model). On Windows, that doesn’t work out so well, because it takes a lot more resources to create another process. So these engines released Windows-specific single-process multi-threaded engines; the only problem was, they weren’t stable. Too many race conditions in some very non-thread-safe code wreaked havoc on many Windows systems, with the PHP developers themselves giving “Stability on IIS” the lowest level of concern.
The Solution: Enter Microsoft’s FastCGI module. It’s a multi-threaded service that creates several processes of the scripting engine and keeps them running thereby eliminating the overhead of creating new processes and also letting you use non-thread-safe binaries without a fear in the world.
Despite all the bad press Microsoft seems to be getting these days from the open source community, even when they do things right, the IIS team has really outdone itself with this project. The benchmarks are quite amazing, and the team seems to genuinely care about pleasing open-source users on the Windows world. While PHP/Zend has released supposedly thread-safe PHP binaries, we’ve been using them here on NeoSmart Technologies for a while, and though they are much better, we’ve still had the occasional access violation error w/ a exit code indicating it was caused by non-thread-safe code.
While most servers running PHP are also running a Unix-based operating system, it’s always good to have a choice. After all, there are quite a few projects out there that require Windows-based servers, have some PHP scripts they’d like to run (the fact that it’s the most popular language for all those highly-used packages should be a clue), and can’t afford another to shell out the cost of another *nix machine. And, as the open-source community would say, it’s all about having as many choices as possible.