ASP.NET async/await part 2

Question

I have a variation of the benefits-of-async/await-on-ASP.NET from this question.

My understanding is that asynchrony is not the same thing as parallelism. So, on a web server, I wonder about how much benefit async/await brings to ASP.NET pages.

Isn't IIS+ASP.NET already really good at allocating threads for requests, and if onen page is busy waiting for a resource the server will just switch to processing another request that has work to do?

There are a limited number of threads in the pool for ASP.NET to use - does async use them any more effectively?

As Mr. Skeet pointed out in answering the question above, we're not talking about blocking a UI thread. We're already multi-threaded and the web response can't be completed until all the request's tasks are done, async or not, right?

I guess what it boils down to is this:

Is there any benefit to an async read of a resource (say a file or DB request) in an ASP.NET page vs. blocking on it?

• svick: Did you actually read the Jon Skeet's answer you mentioned? He does explain the benefits of using async in ASP.NET.
• n8wrl: @svick: Thank you for reading. Yes, I read Jon's answer but in so many cases he's saying "it depends," which I guess is the ONLY answer he can give. I would like to understand the threading implications of async/await on a high-volume web server.

Answer 1

if one page is busy waiting for a resource the server will just switch to processing another request that has work to do?

I don't think so. I would be very surprised if this were the case. It's theoretically possible, but very complex.

There are a limited number of threads in the pool for ASP.NET to use - does async use them any more effectively?

Yes, because when you await something, the thread for that request is immediately returned to the pool.

We're already multi-threaded and the web response can't be completed until all the request's tasks are done, async or not, right?

That is correct. async in a server scenario is all about removing pressure on the thread pool.

Is there any benefit to an async read of a resource (say a file or DB request) in an ASP.NET page vs. blocking on it?

Absolutely!

If you block on a file/service call/db request, then that thread is used for the duration of that operation. If you await a file/service call/db request, then that thread is immediately returned to the thread pool.

One (really cool!) result of this is that you can have a request in progress, and while it's (a)waiting some operation, there are no threads servicing that request! Zero-threaded concurrency, if you will.

When the operation completes, the method resumes after the await - on a (possibly different) thread from the thread pool.

In conclusion: async scales better than threads, so there is definitely a benefit on the server side.

More info: my own intro to async post and this awesome video.

• DavidRR: Benefit caveat from this more recent answer of yours: "If you're talking about ASP.NET MVC with a single database backend, then you're (almost certainly) not going to get any scalability benefit from async. This is because IIS can handle far more concurrent requests than a single instance of SQL server (or other classic RDBMS). However, if your backend is more modern - a SQL server cluster, Azure SQL, NoSQL, etc - and your backend can scale, and your scalability bottleneck is IIS, then you can get a scalability benefit from async."