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 w
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.