WinCache Opcode Cache for IIS
I've been doing some testing with Microsoft over the last month or two which I've simply been itching to talk about, but haven't been able to until now due to NDA. At the start of September the IIS team released a new PHP extension called WinCache for use with PHP/FastCGI on IIS which fills that large whole in PHP performance on IIS where an opcode cache should be. I've done some testing on my beta site, and the results have been very encouraging.
What is an opcode (also called bytecode) cache? In layman terms a PHP script must first be executed on the server to produce the HTML output we see in our browser. This is done every single time a PHP script is requested by any client, and can be a large bottleneck in performance. What the Opcode cache does is store a compiled version of any script that is requested in memory, so subsequent requests for that same script where the content has not change can be served directly out of memory rather than having to be executed from scratch again. This method is well established, and gives PHP a massive performance boost in most cases.
Having an opcode cache is nothing new for PHP on IIS. Back in the day when the community version of FastCGI and PHP ISAPI where king I used to use Turck MMCcache, then eAccelerator (based on MMcache) and finally APC and xCache which all worked great (though config had to be fairly particular). The issue with the PHP/IIS stack started because the existing Opcode cache extensions mentioned above are not compatible with Microsoft's FastCGI module which is now the standard for IIS, and as of PHP 5.3 the only high performance PHP configuration supported on IIS. You can read more about it in this article, but in a nutshell the existing Opcode caches expect FastCGI to spawn additional php.exe processes as a child process of the original php.exe process and share the cached memory between them. With FastCGI on IIS php.exe processes are spawned from the Worker Process executable (w3wp.exe), so what ends up happening is each php.exe process has their own opcode cache that is not shared with other php.exe processes. Making things worse the contents of each cache is lost each time the php.exe process is recycled. The net effect of this is PHP can actually take longer and consume more system resources than by not using any Opcode cache at all.
So how does it perform I hear you ask? Well, rather than test it in some immaculately conceived test bed that is hand picked to give best possible results, I decided to test it on a copy of this very website running Drupal 5, warts and all, to give an example of real world benefits. Keeping in mind my testing to date is all done on an alpha built of Wincache, I was seeing page execution times drop by around 40~45%. This in anyone's book is a massive performance boost, especially when considering the extension is free to download and use and takes but a few minutes to get up and going.
It's been quite some time since I've been this chuffed about the state of play for PHP environments on IIS, so expect to see a some more musings from me over the coming weeks. If performance PHP on IIS is of interest to you, then watch this space.