ThreadPool.SetMinThreads 在 IIS 托管应用程序中不起作用
ThreadPool.SetMinThreads doesn't work in IIS hosted application
我有 ASP.NET 4.6 应用程序，设计为 Web API。它有一个耗时约 60 秒的长 运行ning 操作，但此操作负载不重，让我们想象一下 Thread.Sleep(60000)。
该操作目前不能异步，因为它依赖于第三方非异步库，因此它会阻塞执行该操作的线程 60 秒。当超过 50 个请求同时发送到应用程序时，问题就变成了，新请求在队列中等待（有时多达 400 个）。我试图像这样增加最小和最大线程池线程数：
ThreadPool.SetMinThreads(300, 300);
ThreadPool.SetMaxThreads(500, 500);
这些值已成功更改，如果我 运行 IIS Express 上的应用程序，应用更改并很快分配新线程（大约 3 秒），所有请求都已处理，大家都很高兴:
但是，如果我 运行 IIS 10 上的应用程序，它只分配 40-60 个线程，其余请求正在排队：
如何在 IIS 托管的应用程序中正确使用 ThreadPool.SetMinThreads？
还有其他方法可以达到同样的目的吗？
根本原因在于IIS对Windows10企业的并发请求执行限制：最多可以同时执行10个请求。实际上整个过程我有 46 个线程，只有 10 个线程来自线程池。当我尝试在 Windows Server 2012 上 运行 我的应用程序时，我没有遇到任何问题，因此在几秒钟内在线程池中创建了 400 个线程。
回到这里分享一些建议，但你已经想通了:(
我找到了一篇关于async methods for Web API提升服务性能的文章（其实对你没有帮助），评论里看到了另外一条线索：
I suspect that poor results of the synchronous solution are explained by the fact that IIS running on desktop Windows allows only a limited number of concurrent requests. For example this link suggests 10 requests, which is consistent with your results (req/sec ~= 10/delay).
While it definitely shows the ability of asynchronous solutions to consume less resources, results might be different in a real production environment running Windows Server.
...
...
While numbers suggest that indeed asynchronous version is more performant, the difference is not as devastating as testing on a desktop Windows IIS hints. I hope to return to this topic with more data.
所以原因就在desktop version of the IIS.
IIS 8 on Windows Server 2012 doesn’t have any fixed concurrent request limit, apart from whatever limit would be reached when resources are maxed.
However, the client version of IIS 8, which is on Windows 8, does have a concurrent connection request limitation to limit high traffic production uses on a client edition of Windows.
好像在Windows100张图片是一样的
我有 ASP.NET 4.6 应用程序，设计为 Web API。它有一个耗时约 60 秒的长 运行ning 操作，但此操作负载不重，让我们想象一下 Thread.Sleep(60000)。
该操作目前不能异步，因为它依赖于第三方非异步库，因此它会阻塞执行该操作的线程 60 秒。当超过 50 个请求同时发送到应用程序时，问题就变成了，新请求在队列中等待（有时多达 400 个）。我试图像这样增加最小和最大线程池线程数：
ThreadPool.SetMinThreads(300, 300);
ThreadPool.SetMaxThreads(500, 500);
这些值已成功更改，如果我 运行 IIS Express 上的应用程序，应用更改并很快分配新线程（大约 3 秒），所有请求都已处理，大家都很高兴:
但是，如果我 运行 IIS 10 上的应用程序，它只分配 40-60 个线程，其余请求正在排队：
如何在 IIS 托管的应用程序中正确使用 ThreadPool.SetMinThreads？
还有其他方法可以达到同样的目的吗？
根本原因在于IIS对Windows10企业的并发请求执行限制：最多可以同时执行10个请求。实际上整个过程我有 46 个线程，只有 10 个线程来自线程池。当我尝试在 Windows Server 2012 上 运行 我的应用程序时，我没有遇到任何问题，因此在几秒钟内在线程池中创建了 400 个线程。
回到这里分享一些建议，但你已经想通了:(
我找到了一篇关于async methods for Web API提升服务性能的文章（其实对你没有帮助），评论里看到了另外一条线索：
I suspect that poor results of the synchronous solution are explained by the fact that IIS running on desktop Windows allows only a limited number of concurrent requests. For example this link suggests 10 requests, which is consistent with your results (req/sec ~= 10/delay). While it definitely shows the ability of asynchronous solutions to consume less resources, results might be different in a real production environment running Windows Server. ... ... While numbers suggest that indeed asynchronous version is more performant, the difference is not as devastating as testing on a desktop Windows IIS hints. I hope to return to this topic with more data.
所以原因就在desktop version of the IIS.
IIS 8 on Windows Server 2012 doesn’t have any fixed concurrent request limit, apart from whatever limit would be reached when resources are maxed.
However, the client version of IIS 8, which is on Windows 8, does have a concurrent connection request limitation to limit high traffic production uses on a client edition of Windows.
好像在Windows100张图片是一样的