如何配置 IIS-10 和 FastCGI 以实现高并发？
How do I configure IIS-10 and FastCGI for high concurrency?
场景：我们有一个通过 FastCGI 使用 IIS10 的 php 7 Web 应用程序。我们对我们的应用程序进行了性能测试，发现速度变慢了。我们排除了数据库层。我们查看了 IIS 服务器，即使在重负载下，当应用程序速度急剧下降时，资源也不会紧张……没有 CPU 峰值 没有 RAM 峰值。进一步挖掘，我们得出结论，所有进入的请求都只是在排队。当一些请求需要更长的时间（对于一些需要 1-3 分钟的非常大的报告）时，其他所有请求都会排队等待第一个请求通过。
因此，问题是：我们从哪里着手增加 IIS 一次可以处理的并发请求数？
我在 FastCGI 下找到了这些设置，但文档很少。有人可以解释一下这四个设置的作用吗？
- 实例 MaxRequests
- 最大实例数
- 队列长度
- 每分钟快速失败
我们应该在 DefaultAppPool 下查看任何其他设置吗？
- 队列长度
- 最大工作进程数
- 回收利用
更新：
对于可能搜索此内容的其他人，应该澄清一些事情：
- 此上下文中的请求是指从浏览器到 IIS 服务器的一次调用
- 我们使用 jmeter https://jmeter.apache.org/ 做了一些基本的负载测试
- 从浏览器到 IIS 服务器的请求（为了这个上下文）将像这样处理：浏览器 > DefaultAppPool 工作进程（如果你想增加它，在 IIS 中默认为 1 查看网络花园） > FastCGI 实例（将其视为进程线程，语言很棘手，网络上的人们可以互换使用 threads/processes/instances，这可能会造成混淆）。 FastCGI 默认为 4。这意味着当 5 个并发请求通过时，它们都通过 1 个 DefaultAppPool 工作进程汇集，5 个中的 4 个将由 FastCGI 同时处理，第 5 个将排队。我们对此进行了测试：在 IIS 重新启动后，将不会有 w3wp.exe 或 php-cgi.exe 个进程 运行。当 5 个并发请求进入时：w3wp.exe 将启动并产生 4 个 php-cgi.exe 进程（检查任务管理器）
- 为了增加并发性，我们将 FastCGI“最大实例数”设置为 0，这允许 IIS 根据可用资源决定它想要处理多少，但您也可以将其设置为特定的更高数字。我们对此进行了测试，我相信它是准确的。您可以看到 w2wp.exe 进程和 php-cgi.exe 进程的数量随着请求的增加而增加。
- 您还应该能够增加 DefaultAppPool 工作进程，如果您将其设置为 4 并将 FastCGI 实例也保留为 4，那么从理论上讲，这应该意味着每个工作进程都会产生自己的 4总共 4x4=16 个并发请求的 FastCGI 实例。我还没有进行充分的测试以确保 100% 这就是实际结果。
Instance MaxRequests：控制 FastCGI 进程回收行为。指定 FastCGI 应用程序在进程被回收之前允许处理的最大请求数。默认值为 200。
Max Instances：指定所选 FastCGI 应用程序的应用程序进程池中允许的最大 FastCGI 进程数。这个数字也代表了 FastCGI 应用程序可以处理的最大并发请求数。默认值为 4。
Queue Length：指定为 FastCGI 应用程序池排队的最大请求数。当队列已满时，后续请求 return HTTP 错误代码 503（服务不可用）到客户端。此错误代码表示应用程序太忙。默认值为 1000。
Rapid Fails PerMinute：指定允许向应用程序发出请求的最长时间。如果 FastCGI 进程在单个请求上花费的时间超过指定时间，它将被终止。默认值为 90 秒。
应用程序池:
队列长度：指示 HTTP.sys 在拒绝未来请求之前有多少请求需要排队等待应用程序池。默认值为 1000。
最大工作进程数：指示将用于应用程序池的最大工作进程数。
Recycling中的属性可以参考这个link:
场景：我们有一个通过 FastCGI 使用 IIS10 的 php 7 Web 应用程序。我们对我们的应用程序进行了性能测试，发现速度变慢了。我们排除了数据库层。我们查看了 IIS 服务器，即使在重负载下，当应用程序速度急剧下降时，资源也不会紧张……没有 CPU 峰值 没有 RAM 峰值。进一步挖掘，我们得出结论，所有进入的请求都只是在排队。当一些请求需要更长的时间（对于一些需要 1-3 分钟的非常大的报告）时，其他所有请求都会排队等待第一个请求通过。
因此，问题是：我们从哪里着手增加 IIS 一次可以处理的并发请求数？
我在 FastCGI 下找到了这些设置，但文档很少。有人可以解释一下这四个设置的作用吗？
- 实例 MaxRequests
- 最大实例数
- 队列长度
- 每分钟快速失败
我们应该在 DefaultAppPool 下查看任何其他设置吗？
- 队列长度
- 最大工作进程数
- 回收利用
更新： 对于可能搜索此内容的其他人，应该澄清一些事情：
- 此上下文中的请求是指从浏览器到 IIS 服务器的一次调用
- 我们使用 jmeter https://jmeter.apache.org/ 做了一些基本的负载测试
- 从浏览器到 IIS 服务器的请求（为了这个上下文）将像这样处理：浏览器 > DefaultAppPool 工作进程（如果你想增加它，在 IIS 中默认为 1 查看网络花园） > FastCGI 实例（将其视为进程线程，语言很棘手，网络上的人们可以互换使用 threads/processes/instances，这可能会造成混淆）。 FastCGI 默认为 4。这意味着当 5 个并发请求通过时，它们都通过 1 个 DefaultAppPool 工作进程汇集，5 个中的 4 个将由 FastCGI 同时处理，第 5 个将排队。我们对此进行了测试：在 IIS 重新启动后，将不会有 w3wp.exe 或 php-cgi.exe 个进程 运行。当 5 个并发请求进入时：w3wp.exe 将启动并产生 4 个 php-cgi.exe 进程（检查任务管理器）
- 为了增加并发性，我们将 FastCGI“最大实例数”设置为 0，这允许 IIS 根据可用资源决定它想要处理多少，但您也可以将其设置为特定的更高数字。我们对此进行了测试，我相信它是准确的。您可以看到 w2wp.exe 进程和 php-cgi.exe 进程的数量随着请求的增加而增加。
- 您还应该能够增加 DefaultAppPool 工作进程，如果您将其设置为 4 并将 FastCGI 实例也保留为 4，那么从理论上讲，这应该意味着每个工作进程都会产生自己的 4总共 4x4=16 个并发请求的 FastCGI 实例。我还没有进行充分的测试以确保 100% 这就是实际结果。
Instance MaxRequests：控制 FastCGI 进程回收行为。指定 FastCGI 应用程序在进程被回收之前允许处理的最大请求数。默认值为 200。
Max Instances：指定所选 FastCGI 应用程序的应用程序进程池中允许的最大 FastCGI 进程数。这个数字也代表了 FastCGI 应用程序可以处理的最大并发请求数。默认值为 4。
Queue Length：指定为 FastCGI 应用程序池排队的最大请求数。当队列已满时，后续请求 return HTTP 错误代码 503（服务不可用）到客户端。此错误代码表示应用程序太忙。默认值为 1000。
Rapid Fails PerMinute：指定允许向应用程序发出请求的最长时间。如果 FastCGI 进程在单个请求上花费的时间超过指定时间，它将被终止。默认值为 90 秒。
应用程序池:
队列长度：指示 HTTP.sys 在拒绝未来请求之前有多少请求需要排队等待应用程序池。默认值为 1000。
最大工作进程数：指示将用于应用程序池的最大工作进程数。
Recycling中的属性可以参考这个link: