Major revision of FastCGI/PHP article on IIS.NET

Since the time we have published the article about installing FastCGI and PHP on IIS 7.0 it has become one of the most popular articles on Also it has received a lot of comments from site visitors. Today, we are publishing the updated version of this article that contains more up-to-date information and addresses most of the feedback from community. Here is what this article includes now:

Please take a look at the new content and leave comments if you have any questions of feedback.

Acknowledgments: I would like to thank IIS.NET visitors who have provided their comments and corrections to this article. Also I thank Jake and Bill for doing a final review of the article.

6 thoughts on “Major revision of FastCGI/PHP article on IIS.NET”

  1. Oops… I forgot to mention that the non-thread-safe installer on can be used after PHP 5.2.7, which is currently in RC stage, is released. That’s because the issue documented in has been fixed.

    The installer can install the php-cgi.exe (with Other CGI selected) and allow users to install PHP extensions without any manual modification.

    The RC of the installer can be found on

  2. In our tests we saw that increasing the InstanceMaxRequests improved the performance of FastCGI with PHP slightly. However, if this setting is configured to a value bigger than 500 (PHP’s default for process recycling), then it may conflict with PHP recycling behavior (as described Since the performance difference between InstanceMaxRequests set to 200 vs. 1000 was not significant, but the chances of getting server errors with default value set to 1000 were higher, it was decided to change the default to 200. However it was too late to change it for IIS 6, as the FastCGI extension was about to be shipped then.

  3. Thanks! However, besides the InstanceMaxRequests, the MaxInstances default has also been changed from 10 to 4. Is 4 better than 10?

  4. For MaxInstances there is no technical reason for the difference in defaults. One value is not better than the other. For development purposes either of the defaults would work fine. For production deployment you would probably need to fine tune this number anyway to achieve full CPU load.

  5. Pingback: RuslanY Blog

Leave a Reply

Your email address will not be published. Required fields are marked *