根据IIS.net's guide.，使用 WP-SuperCache 在 IIS 7 (Windows Server 2008) 上运行 WordPress
运行良好，但最近我们更改了某些文件夹的权限和管理员密码，由于 PHP-cgi.exe 进程，我们的 CPU 使用率出现了巨大的峰值。
这让我相信它不是缓存，但是页面本身在底部有“使用 WP-SuperCache 缓存”的 cmets，并且缓存似乎工作正常。
这里还有什么问题？
【问题讨论】：
标签： php wordpress iis caching cgi
查看该任务管理器看起来好像它在每个请求上都缺少缓存。再加上那篇文章可以追溯到 2008 年，很难说所写的指示是否仍然有效。 WP-SuperCache 的某些东西可能已经改变了。
我会推荐使用 W3 Total Cache。我已经在 Windows Server 2008 和 IIS 7 上对它进行了广泛的测试，效果很好。它还兼容并利用 PHP 的 WinCache 扩展。如果您有兴趣，它还有一些其他很棒的功能、缩小、CDN 支持等。它是一个非常棒的 WordPress 性能插件。你可以在这里获取插件，http://wordpress.org/extend/plugins/w3-total-cache/
需要检查的其他事项...
应用程序池的大小是多少？ （进程数？） 确保您使用的是 PHP 5.3。 确保您使用的是 WinCache。 确保将 MaxInstanceRequests 设置为小于 PHP_FCGI_MAX_REQUESTS。绝对不允许 PHP 处理回收应用程序池。默认值为 10K 请求。如果您在负载测试期间看到这些结果，那么这可能是原因。增加 MaxInstanceRequests 并保持它比 PHP_FCGI_MAX_REQUESTS 少一。
希望对您有所帮助。
【讨论】：
我想我可能已经找到了解决方案，或者至少找到了解决这个问题的方法，至少它似乎对我可靠地工作。
尝试将 IIS 服务器 --> FastCGI 设置下的 Max Instances 设置设置为 1。
在我看来，只有某些请求会导致 php-cgi.exe 进程变得流氓并占用 CPU，通常是在更新帖子时。在阅读有关此问题的其他帖子时，其中一位提到了 Max Instances 设置，并将其设置为默认值 0 或自动。我想知道当事情不应该是这样时，这是否可能不会产生良好的效果。我猜测（但这不是我的专业领域）是否某个请求导致进程锁定，所以 FastCGI 只是创建另一个请求，同时保留第一个请求。不知何故，似乎只有一个实例允许 PHP 从锁定状态继续前进，并且 cpu 保持在控制之下。
对于具有高级别请求的服务器，将 FastCGI 设置为仅单个实例可能并不理想，但它肯定会超过我之前遇到的延迟。与 WP-SuperCache 和 WinCache 结合使用，现在似乎进展顺利。
【讨论】：