Making PHP rock on Windows/IIS
Right as I was about to go home, one of our developers comes in to tell me some good news about our new IIS7 FastCGI module. So, I figure I would shed some light on our recent work to improve hosting PHP (yes, you read right, PHP) applications on Windows/IIS.
The IIS team is committed to providing production quality support for PHP applications, which is currently lacking on the Windows platform. It turns out, while 70%+ of PHP developers develop on Windows, actually hosting PHP applications on Windows is not recommended by the PHP community for production. Why?
Here is the reason:
IIS is a multi-threaded web server, because multi-threading is really the only way to achieve high-concurrency high-performance server applications on Windows (processes aren’t as cheap as they are on Nix). ASP.NET, ASP, and other IIS application frameworks and components are all thread safe, and the IIS extensibility model is designed to allow high-performance / asynchronous processing. PHP has not been designed with multi-threading in mind, and while today the PHP core is thread safe (http://www.php.net/), many extension libraries PHP applications use are not and therefore cannot be reliably hosted in a multi-threaded environment. You may get lucky, but unless you are making sure the extensions you are using are thread-safe (except for extensions bundled with the PHP core distribution, I cannot find any list of known-safe extensions anywhere), you are sure to hit deadlocks and memory corruption when running PHP in multi-threaded mode with the PHP ISAPI extension for IIS.
The only supported single-request-per-process option on Windows/IIS today is to use CGI (http://www.w3.org/CGI/). In a nutshell, CGI hosts spawn a new application process for each incoming request, send in request data via environment variables/stdin, receive the response back via stdout, and kill the process. Result - the performance on Windows is horrendous!
So, we set out to build a FastCGI host for PHP, which is another commonly supported mode for PHP applications that uses the next generation FastCGI protocol (http://www.fastcgi.com/devkit/doc/fcgi-spec.html), that still allows for a single request per process execution but maintains a pool of reusable processes. This should be quite promising according to our internal test results, and I cannot wait until it’s ready for primetime.
Bill Staples and I gave the first public preview of our work to make PHP rock solid on the Windows/IIS platform to a number of key PHP developers last week … I demoed our brand new native response caching feature in IIS7 that launched the throughput of my sample dynamic PHP app (QDIG) from 40 RPS to 1600+ RPS (it was client bound at that point, so I couldn’t even come close to maxing the server).
Here is some early news coverage of the event: http://searchopensource.techtarget.com/columnItem/0,294698,sid39_gci1218130,00.html.
The article quotes me as saying “nothing concrete has come out of this yet” – but something concrete is definitely coming. For starters, our FastCGI PHP host platform that should get us most of the way there. There are definitely other things we need to do to make the experience rock end to end, including providing support for commonly-used Apache features like mod_rewrite for url rewriting, and a number of others, but one thing is clear - PHP on IIS7 is going to kick ass!
If you have any ideas / specific suggestions for how we can make PHP run better on Windows, please don’t hesitate to comment.
Stay tuned for more updates on this effort.
For the past 5 years, I was the core Program Manager for Microsoft ASP.NET 2.0 and IIS 7.0 products. I drove the design and development of the IIS 7.0 web server core, the IIS FastCGI support, the AppCmd command line tool, the ASP.NET Integrated pipeline, and other special projects around server security, performance, and scalability. Now, I am working on my own on cutting edge web server tech on top of the Microsoft IIS platform, and continue blogging about it here.