What is the impact of async action method on IIS?

Question

I need help in understanding how async action method can improve performance of IIS (and eventually my application).

First I tried to create Server Unavailable (503) with following code and setup

• Application Queue Length: 10
• IIS - Threads per processor limit: 2
• Processors: 4

Sent 20 requests with SOAP UI and when tried from the browser, the browser showed 503, which is what I expected.

Then I made following changes in code

Sent 20 requests again with SOAP UI and when tried from the browser, the browser again showed 503, which I wasnt expecting.

Wouldn't the async and await release the thread to accept new connections?

Is my understanding correct on following

1. Maximum number of concurrent requests the server can accept at any given time is : (IIS Threads per processor limit * Number of processors + Application Queue Length) 18 in my case?
2. 19th request would get a 503 in case of synchronous action methods?

Answer 1

Defining an async action method does not affect how many requests IIS can serve of the same type. You are correct when you say that the thread itself is released during the Task.Delay call, but the request is still there in the queue.

You would see a difference only if you sent a few requests to the async TimeOnServer action like this one, and a few other requests of a different type that could use more threads - e.g. performing some parallel work with PLINQ. In that case your 'other' requests would be served at a higher rate.

Here is an old but really useful article that describes the benefits clearly:

Async Programming : Introduction to Async/Await on ASP.NET by Stephen Cleary

Answer 2

As Miklós noted, asynchronous requests will yield their thread to the ASP.NET thread pool, but the request itself is still active. So, to see the benefit of asynchronous actions, you'll want to restrict the thread pool and not restrict the queue.

Another common mistake - particularly with browser testing - is that by default the ASP.NET session state will serialize requests for the same session.

I have a gist here that demonstrates how async calls yield threads.