ThreadPool.SetMinThreads在IIS托管应用程序中不起作用

Question

我有ASP.NET 4.6应用程序，它被设计为Web API。它有一个长时间运行，大约需要60秒，但此操作不会重载，让我们的成像像Thread.Sleep(60000)一样。 此操作此时不能是异步的，因为它依赖于第三方非异步库，因此它会阻止执行此操作的线程持续60秒。当同一时刻向应用程序发送超过50个请求时，问题就出现了，新请求在队列中等待（有时高达400）。我试图增加最小和最大线程池线程数，如下所示：

ThreadPool.SetMinThreads(300, 300);
ThreadPool.SetMaxThreads(500, 500);

这些值已成功更改，如果我在IIS Express上运行应用程序，则会应用更改并快速分配新线程（大约3秒），处理所有请求，每个人都很高兴：

但是，如果我在IIS 10上运行该应用程序，它只分配40-60个线程，其余请求正在排队：

如何正确使用IIS托管应用程序中的ThreadPool.SetMinThreads？ 还有其他方法可以实现同样的目标吗？

Answer 1

根本原因是IIS 10限制了Windows 10 Enterprise的并发请求执行：最多可以同时执行10个请求。实际上我整个进程有46个线程，只有10个线程来自线程池。当我尝试在Windows Server 2012上运行我的应用程序时，我没有遇到任何问题，因此在几秒钟内在线程池中创建了400个线程。

Answer 2

回到这里分享一些建议，但你已经把它弄好了:(

我发现了一篇关于使用async methods for Web API改善服务性能的文章（实际上对你没有帮助），在评论中看到了另一条线索：

  

我怀疑同步解决方案的不良结果可以通过在桌面Windows上运行的IIS仅允许有限数量的并发请求来解释。例如this link建议10个请求，这与您的结果一致（req / sec~ = 10 / delay）。   虽然它确实显示了异步解决方案消耗更少资源的能力，但在运行Windows Server的实际生产环境中结果可能会有所不同。   ...   ...   虽然数字表明确实异步版本的性能更高，但差异并不像在桌面上进行Windows IIS 提示那样具有破坏性。我希望通过更多数据回到这个主题。

原因正好在desktop version of the IIS.

  

Windows Server 2012上的IIS 8没有任何固定的并发请求限制，除了资源最大化时达到的限制。

     

但是，Windows 8的客户端版本确实具有并发连接请求限制，以限制Windows客户端版本上的高流量生产使用。

似乎在Windows 100中图片是一样的。