ASP.NET async/await part 2

后端 未结 1 1437
心在旅途
心在旅途 2021-01-13 06:27

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

1条回答
  •  醉梦人生
    2021-01-13 06:34

    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.

    0 讨论(0)
提交回复
热议问题