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

Question

I have ASP.NET 4.6 application that is designed as Web API. It has one long running operation that takes about 60 seconds, but this operation isn't heavily loaded, let's imaging that like Thread.Sleep(60000) .
This operation cannot be asynchronous at the moment because it depends on third party non-async library, therefore it blocks a thread executing this operation for 60 seconds. The problem becomes when more than 50 requests are sent to the application at the same moment, new requests are waiting in a queue (sometimes up to 400). I tried to increase minimum and maximum number of thread pool threads like this:

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

These values are successfully changed, and if I run the application on IIS Express, the changes are applied and new threads are allocated very quickly (about 3 seconds), all requests are processed, everyone is happy:

However if I run the application on IIS 10, it just allocates 40-60 threads and the rest of requests are being queued:

How can I use ThreadPool.SetMinThreads in IIS hosted applications properly?
Are there any other ways to achieve the same?

Answer 1

The root cause is in IIS limit of concurrent requests execution for Windows 10 Enterprise: there are maximum 10 requests can be executed simultaneously. Actually I had 46 threads for the entire process and only 10 threads were from the thread pool. When I had tried to run my application on Windows Server 2012, I didn't experience any issues, so 400 threads were created in the thread pool during few seconds.

Answer 2

Returned back here to share some advices, but you've already fegured it out :(

I found an article regarding the service performance improvement with async methods for Web API (which, in fact wouldn't be helpful for you), in comments there saw another clue:

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.

So the reason is exactly in 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.

Seems like in Windows 100 the picture is the same.