Wincache performance on a live site

Earlier this month the IIS team released the first release candidate of their exciting new Wincache caching extension for PHP. In my view this new extension is the most significant work the IIS Team have done for hosting PHP applications on IIS since the they released the FastCGI handler for IIS back in 2006.

Claiming that Wincache is the best PHP tool to come from the IIS team since the FastCGI handler is a big call, however I do believe it is valid. Being an interpreted script, PHP can put heavy loads on your server resources which can greatly effect performance. This is where an opcode/file cache like Wincache comes in as its function is to vastly reduce PHP script processing times by storing the compiled bytecode of your PHP scripts in memory, and prior to Wincache there hasn't been a viable PHP opcode/file caching option out there for use on IIS/FastCGI.

Instead of showing you all sorts of test lab scenarios with theoretical claims of what performance increases should be achievable in the real world, I decided to use this very site with real web traffic to give you an idea of what Wincache can deliver. Based on the popular Drupal content management system, this should give you some real insight into the sort of performance improvements you can expect from utilising the Wincache extension.

Rather than reeling of statistics, I'm simply going to let the graphs do the talking. The graph below shows the average page generation times with +/- 1 standard deviation over the 23rd of October without the Wincache extension enabled.

Without Wincache

From this you can see the average page generation time for the day hung around the 400ms mark. Below is the same graph from the following Friday (to keep traffic levels as comparable as possible) with the Wincache extension in full swing.

With Wincache

As you can see here the page generation time has been slashed to around the 150ms mark, which equates to a performance boost by around 250%. In anyone's book this is a massive performance increase, and given it takes about 5 minutes to implement with no code level modifications or optimisations makes it even more remarkable. I'm sure you'll agree that these figures give a lot of weight to my claim that this is the biggest release to come from the IIS team for PHP on IIS since the release of the FastCGI extension.

If you have been testing the Wincache extension as well, then I'd love to hear your feedback in the comments below. If you need support using Wincache, then I'd be more than happy to help. However I would ask you to please post support requests in the forums so as to keep discussion on topic.

Average rating
(0 votes)

Comments

Anonymous's picture

Hi Dominic, Thanks for this

Hi Dominic,

Thanks for this bench.

Just a question, what do you mean by stddev ?

I use WinCache on an IIS 6 test server for about one month and I see also very good results.

I actually use PHP 5.2 TS with FastCGI 1.0 and eAccelerator and I am waiting for the final versions of the following components to do a huge update of my production server :

* FastCGI 1.5
* WinCache 1.0
* PHP 5.3.1 (5.3.0 too bugged)

I hope also we will have soon PGO binaries of PHP and why not stable x64 binaries. All of that is very exciting for me who use yet last year PHP as ISAPI...

Julien

Brashquido's picture

Exciting times for PHP on IIS

Yeah, I think 2010 will be a big year for PHP on IIS. The three items you've identified are what I am looking forward to as well. Especially Wincache and PHP 5.3.x as I know Pierre has done a lot of work there replacing old POSIX emulation code with Windows native calls. I really think Pierre is the most instrumental PHP on Windows guru to come along since Shane Caraveo.

I haven't read a lot about PGO, but it does sound very promising if they are able to get the build process fine tuned. Think that may be off in the future though, along with stable x64 binaries as getting 5.3.x stable and fast I imagine will take considerable effort. I did look at compiling my own x64 binaries for a while, however I didn't think it was work the effort considering the biggest advantage I could see was the removal of the 4GB memory limit of the 32-bit binaries (there aren't too many PHP web apps that need more than this).

Anyway, to your question; stddev means standard deviation, which is a statistical measure. In a nutshell it gives you an idea of the spread of a set of figures in relation to the average. If there is a large standard deviation then there is a lot of variation between the values, if not then the values are close together. In regards to web page generation times, then you'd want a low standard deviation, which would mean each web page is delivered to the user in roughly the same amount of time.

----------------
Dominic Ryan
5 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster

Anonymous's picture

Thanks for the infos. About

Thanks for the infos.

About Pierre, I know he was working on APC for Windows and FastCGI. But what future for this solution now...

I have emailed Garrett Serack, who has developped the new PHP build process, and he says me that a new build optimized with PGO and based on PHP 5.3.1 will be avaible next week.

The last PGO binaries he has published are based on PHP 5.3.0 RC2 :
http://www.fearthecowboy.com/post/PHP-53-RC2-Highly-Optimized-for-Windows-available.aspx

Julien

Brashquido's picture

Nice info on the PGO PHP Builds

Wow! Didn't even realise PGO builds were that far along. I'll have to read up on what PHP apps exactly they are using for their profiling.

----------------
Dominic Ryan
5 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster

Anonymous's picture

What are you using to track that data?

What are you using to track the page execution time and make the graphs? Is that from script start or from request start?

Brashquido's picture

Using Drupal Timer

Those stats are generated from the timer built into the Drupal CMS which I use, and therefore will be from script start. If you are wanting to see how much time IIS taking from first byte to last byte, then the simplest thing to do would be to enable the time-taken field in your IIS logging.

----------------
Dominic Ryan
5 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster