Efficiency of the Go Live Microsoft FastCGI handler

Using FastCGI with PHP on IIS is nothing new to me as I've been using the PHP community version of FastCGI which was originally written by Shane Caraveo since 2003, however rules to tweaking the performance of FastCGI on IIS have changed a little bit with the Go Live release of Microsoft's FastCGI handler last month. Historically when configuring PHP on IIS to use FastCGI with the PHP community version or the technical preview releases from Microsoft you increase the number of PHP CGI instances until you found the sweet spot for your particular environment. Well, getting the number of PHP instances right just got a lot easier with the Go Live release. Rick James is one of the IIS Team who has been working hard on the FastCGI handler, and in a recent forum post on iis.net he spoke about a new directive in the Go Live release of Microsoft's FastCGI handler called ResponseBufferLimit. What this does is buffer the response from FastCGI applications such as PHP so that when they are finished they can be released to serve the next request instead of being tied to the client until the response is delivered. If the response of the FastCGI application is less than the buffer size then it is entirely possible that the FastCGI application (PHP, etc) is already processing the next request before the client has even received the first byte of the response. This drastically reduces the number of CPU bound FastCGI applications needed to achieve maximum throughput, as theoretically you should only need one FastCGI application for each CPU in your system to achieve this. Only caveat is that if the FastCGI application response is larger than the ResponseBufferLimit value, then that particular FastCGI application will go on serving the client. This is not the case with the PHP community version of FastCGI or the technical preview releases of Microsoft's FastCGI handler, as the FastCGI applications here were tied to the client until the request was completed and deliveredt. This is why increasing the amount of PHP instances with these versions resulted in a higher throughput. I decided to give this theory a test, and using the same environment from my article on performance tuning PHP 5.2 on IIS I completed a series of tests where the only configuration change was the MaxInstances value in fcgiext.ini. Beginning with 1 PHP CGI process for the first test, I increased it to 2, then 4, 8, 12, 16, 20 and 24. After I did this I averaged the successful requests per second and time to last byte values across all three of the PHP applications used (Gallery 2.2.3, Drupal 5.3 and Wordpress 2.3) and compiled them into the graph you can see below;

From this test you can see that what Rick said about this ResponseBufferLimit setting is true. In my dual core test system the performance increased significantly from one PHP instance to two, however above this throughput did not increase and if anything decreased slightly. Ideally I would love to perform this test again on a quad core system to emphasis the relationship between achieving maximum throughput with the number of PHP instances and CPU count. Not sure where this leaves systems with only one CPU though, but as time goes on I'd expect those to be the exception rather than anything.
Average rating
(0 votes)

Comments

Anonymous's picture

How many Apps Are CPU Bound?

I imagine if your app calculates random numbers then it will be CPU bound, but how many apps really are? Isn't the database usually going to be where most time is spent? I'd love to see some metrics comparing MaxInstances in a real app that is fairly common such as phpBB or MediaWiki or Wordpress.