wids服务器php-cgi,win2008服务器，FastCGI完美设置教程

在WIN2008的IIS7上使用FASTCGI调用PHP-CGI.EXE,默认只有4个进程，这样对于大流量的网站为说，进程数不足带来的进程排队现象十分严重，解决方案如下。

32位系统 http://www.iis.net/Downloads/files/AdminPack/TP2/AdminPack_x86.msi

64位系统 http://www.iis.net/Downloads/files/AdminPack/TP2/AdminPack_amd64.msi

下载如下工具，安装后，如下图。

添加

PHP_FCGI_MAX_REQUESTS = 10000

添加后，不用重启IIS,就能在进程管理器看到效果。

似乎并没有达到设定的值，不过浏览网站明显感觉到性能的提示。

内存占用~~ 其实微软的系统有一个不好处在于， 服务器的内存占用，要尽量让服务去使用，而并不像客户端使用一样，留足够多的内存给用户的应用程序。

我在这里要提醒大家注意的是以下两个参数值得设置：

InstanceMaxRequests：fastcgi进程(php-fcgi.exe)能处理的最大请求数，超过了就要回收，默认是200

PHP_FCGI_MAX_REQUESTS：php自身控制的最大请求数，默认是500

既然要用fastcgi去运行cgi，那肯定是不想php自身去限制最大请求数！！

所以，一定要保证InstanceMaxRequests小于 或 等于 PHP_FCGI_MAX_REQUESTS，这样php自身永远没有机会去回收进程。

可以看micorsoft说的：

Make sure that FastCGI always recycles Php-cgi.exe processes before native PHP recycling starts. The configuration property instanceMaxRequests controls the FastCGI process-recycling behavior. This property specifies how many requests FastCGI will process before recycling. PHP also has a similar process-recycling functionality that is controlled by the environment variable PHP_FCGI_MAX_REQUESTS. By setting instanceMaxRequests to a value that is smaller than or equal to PHP_FCGI_MAX_REQUESTS, you can make sure that the native PHP process-recycling logic will never start.

建议

512M 内存的改maxInstances=50

1G 内存的改maxInstances=80

2G 内存的改maxInstances=140

再修改

InstanceMaxRequests=

把这个值改小

建议

512M 内存的改InstanceMaxRequests=200

1G 内存的改InstanceMaxRequests=300

2G 内存的改InstanceMaxRequests=500

改完， 重启IIS。

instanceMaxRequests  PHP_FCGI_MAX_REQUESTS  这两个参数决定了一个php-cgi进程被创建出来之后，最多接受的PHP请求数，在lighttpd中默认配置是10000。也就是说这个php-cgi进程每接受10000次PHP请求后会终止，释放所有内存，并重新被管理进程启动。如果把它降低，比如改成100，那么php-cgi重启的周期会大大缩短，偶然的高内存操作造成的问题影响时间也会缩短。

maxInstances 这个参数指定可以启动的最大实例数目，即php-cgi.exe进程的数目。如果把它降低，比如改成100，那么在任务管理器的进程中最多只有php-cgi.exe进程，php-cgi.exe所占用的总内存将大大减少。

我现在用的服务器为windows 2003操作系统，4G内存，一个php-cgi.exe程序占用7－25M内存，我把maxInstances值调为300，减少了php-cgi.exe进程的总数量，占用内存也减小了，反应速度比以前快了不少，至少调整到多少，可根据您的站点访问量来决定。

转自：http://www.itdaan.com/blog/2016/02/22/8cb2e9f869a9e35464d3214bb8b1fe82.html