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 http://learn.iis.net. 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:
- Overview
- Enabling FastCGI support in IIS 7.0
- Install and Configure PHP
- Configure IIS to handle PHP requests
- Best practices for configuring FastCGI and PHP
- Per-site PHP configuration
- URL rewriting for PHP applications
- Related Resources
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.
Hello,
I noticed that the default parameter values of the IIS 7.0 FastCGI Module is different from those in the FastCGI Extension for IIS 6.0. Is there any reason for that?
(Also posted at http://forums.iis.net/t/1152607.aspx)
Oops… I forgot to mention that the non-thread-safe installer on http://www.php.net/downloads.php can be used after PHP 5.2.7, which is currently in RC stage, is released. That’s because the issue documented in http://bugs.php.net/bug.php?id=45275 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 http://windows.php.net/qa/
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 http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-70/#PHP_Recycling_Behavior). 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.
Thanks! However, besides the InstanceMaxRequests, the MaxInstances default has also been changed from 10 to 4. Is 4 better than 10?
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.