Performance tuning PHP 5.2 on IIS

With the Go Live release of Microsoft's FastCGI handler last month I decided that it was time to put PHP 5.2.x through its paces and see just how fast I can get it to go on IIS. Following in the footsteps of Bill Staples who performed a similar test with PHP and the early release of the Microsoft FastCGI handler on IIS7, I decided to use Bill's WCAT (Web Capacity Analysis Tool) scripts and just modify the URL component for my own test. However, unlike Bill I have elected to use the Go Live release of Microsoft's FastCGI handler on IIS 6 with a mix of Zend and community versions of PHP 5.2.4. Not only that, I have also chosen not to use a web application which is written purely in PHP such as Bill did with Qdig, but have instead decided to use some popular everyday PHP web applications which use a MySQL database for data storage. To try and get a good cross section of PHP/MySQL based web applications I selected Wordpress 2.3 for blogging, Drupal 5.3 for a CMS and Gallery 2.2.3 for a photo gallery. Lets see the results.

The Test Environment

For the test I used clean install of the 32-bit version of Windows 2003 R2 Standard Edition running Service Pack 2 with all available updates installed. This was installed on a system with the following components;

  • AMD Athlon 64 X2 3800+ EE
  • Asrock ALive NF6G -VSTA
    • NVIDIA nForce 430 MCP Chipset
    • Realtek RTL8201CL 100Mbit NIC
  • 2 x 512 Geil DDR2 PC6400 RAM
  • 250GB Maxtor 7200RPM IDE Hard Drive

The PHP environments consisted of the thread safe and non thread safe PHP community distributions of PHP 5.2.4 used in conjunction with the Go Live release of Microsoft's FastCGI handler and also eAccelerator 0.9.5.2 (with thread safe PHP distro only). The Zend Core 2.5 was also used which is an optimized non thread safe build of PHP 5.2.4 and comes with a bundled version of the Microsoft FastCGI handler.

The community versions of PHP were configured in CGI, CGI non thread safe, ISAPI, ISAPI with eAccelerator 0.9.5.2, FastCGI, FastCGI non thread safe and FastCGI with eAccelerator 0.9.5.2. The Zend Core was left as a default installation as it is an optimized build, however all environments shared the same php.ini directive values which were left as default as per the php.ini-recommended template with the exception of session and upload directories. In addition the mbstring, mcrypt, gd, MySQL and gettext PECL extensions were loaded as they were required for complete operation of one or more of the web applications being tested. Each of the web applications being tested where installed using the default values only with no further content added.

MySQL 5.0.45 was installed and configured using the server template in the instance configuration wizard. IIS 6 was installed using the defaults, and all web applications were accessed via IP address over a 100Mbit switched network to prevent name resolution and network latency. As mentioned already the WCAT scripts Bill used in his original test of PHP on IIS7 were also used in this test with the only modification to reduce the number of requested URL to just the web application index page. This WCAT script simulates 20 concurrent users for 20 seconds, and I used the average number of successful requests (status 2xx) per second and average time to last byte (TTLB) reported by WCAT as my results.

Caveats & Considerations

Before we move onto the test results, I would like to make it very clear that they are illustrative only and in no way should be taken as absolute values. In saying that though I did make every effort to ensure a level playing field in my testing environment, so you should find them to be fairly reliable. Some other factors to consider in the test results is that all the web applications where installed using their default values, and no content was added other than what is included with the default install. Another consideration is that due to a bug in libmysql.dll in PHP 5.2.4 (MySQL client 5.0.45) I had to roll back to the libmysql.dll included with PHP 5.2.1 (MySQL client 5.0.27). Finally, this test only takes performance into account, and does not take other key factors such as stability and security into consideration.

Comments

Anonymous's picture

Hi

Try to use FCGI+NTS+APC (http://pecl.php.net/package/APC). This may be faster then FCGI+TS+eaccelerator.

Brashquido's picture

Hi There, I have tried that

Hi There,

I have tried that combination in the past, but with very little success. I've found that both xCache and APC are not very stable with IIS. It has been some time since I looked though, so will perhaps give it another try.
----------------
Dominic Ryan
3 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster

Anonymous's picture

Similar results on LAMP

I did a benchmark comparison of Drupal 5.6 and WP 2.3.3 about a month ago. I started with clean installs of each app. I then used the devel module on Drupal to create 1,000 nodes with 40 comments each and 20 categories. I then converted that data over to work in WP, so each app was working with the same data.

Next I didn't use any plugins/modules on either one. I also got rid of all blocks and widgets from both apps. That left me with basically the same setup on each system (including same number of items to show on the front page).

Running numerous benchmarks under different scenarios, I ended up seeing Drupal serving almost 3 times the requests in the same amount of time as Wordpress. On single item views with comments, Drupal was serving about 4 times the requests.

I have done development in both systems professionally for a couple of years now, and this laid my suspicions to rest. It appears to me that Wordpress needs a lot of attention in the performance department. It's a great system that is easily customized, but it lacks in the area of optimized code.

The biggest area I have noticed this bottleneck in comes from the filters. For every page view, each post or comment is ran through numerous filters (including the wpautop). This is a total waste of resources. Why filter these items on every view, when they aren't being changed? Just filter them at insert/update times and be done with it. Also if you look through those filters, they are heavily riddled with numerous regex functions. These also take up a lot of cycles. That alone is another good reason to move the filtering from the render stage, to the save stage.

Thanks for an interesting read. I never work with IIS, but it is good to see the decent performance come out of it.

Brashquido's picture

That's really interesting to

That's really interesting to hear! I've often wondered how PHP app performance stacks up on IIS compared to *nix/Apache combinations. Thanks for the post.
----------------
Dominic Ryan
4 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster

Anonymous's picture

Interesting

Well i always thought apache php go together but it seems windows server is a viable option especially on testing environments where I always seem to use a windows computer

Girish
(author - http://channel8.msdn.com/Posts/Drew-Robbins-in-Teched-IIS-and-PHP-integration/ )

Anonymous's picture

FastCGI .ini

Hello,

I have a site with 15000 anonymous user for day.
How I have to configure the fcgiext.ini to optimize the fastcgi handler ?

Now,

[types]
php=c:\php\php-cgi.exe
QueueLength=1000
MaxInstances=15
ActivityTimeout=120
RequestTimeout=120

thanks
Martín

Brashquido's picture

Hi Martin, Please start a

Hi Martin,

Please start a new forum thread if you wish to get help with your individual environment.
----------------
Dominic Ryan
4 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster

Anonymous's picture

Why use thread safe php with FastCGI

Just curious. Why would you use thread safe PHP with FastCGI? Did you test with non thread safe PHP with eA? The whole idea I thought was that FastCGI would allow you to run non thread safe PHP code safely the way PHP was originally written, but handle it in a way that is much faster than CGI every could.

Brashquido's picture

No stable non-thread safe Opcode caches

In a nutshell, there are no open source non-thread safe opcode caches that run on Windows/IIS (EA, APC, xCache, etc). Long story short there are some design flaws in all of the open source opcode caches where they have all been designed more or less only to work on a *nix/Apache platform.

There is no harm in using thread safe binaries with FastCGI, it just isn't ideal. Have a read through this article for further details. I don't expect this issue to be fixed any time soon.

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