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?

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.