Why use async controllers, when IIS already handle

问题:

I wonder why I should bother using async Task on controllers, when IIS already handles the concurrency for me?

http://msdn.microsoft.com/en-us/library/dd560842.aspx

回答1:

Async / await in asp.net is not about concurrency, it's about blocking or not blocking threads.

If you use async / await you release the thread while you're waiting for an operation. If this operation is CPU-bound, there's no benefit (it'll be even slightly slower because of the context switching)

If the operation is IO-bound though (network, disk, ...) it means that IIS can handle more concurrent requests, since you're not blocking any threads that are doing nothing.

回答2:

As others have pointed out, async allows the request thread to return to the thread pool while it's doing an asynchronous operation. With synchronous handlers, your server will end up with threads blocked on I/O, essentially doing nothing important but also not able to be used for other requests while they're blocked. async just frees up those threads so that they are useful all the time.

So, the first thing of note is that the question "async or the thread pool" is the wrong question. When you use async, you're allowing ASP.NET to make maximum use of the existing thread pool. async takes the existing (parallel) concurrency in ASP.NET and adds (asynchronous) concurrency to achieve greater scalability.

But the question remains of "why"? The reasons are twofold: async can scale further than (just) the thread pool, and async is also more responsive. As mentioned in the comments on the other answers, threads are pretty heavyweight objects to be wasting unnecessarily; the memory for asynchronous operations is much less than that used by a thread. The second reason is also important: when a sudden burst of requests come in, the thread pool (by itself) can only expand at a limited rate; async enables the thread pool to handle bursts of requests much more efficiently.

回答3:

When processing the request, you are likely to access resources that may take a significant amount of time (eg. round trip to a database is likely to be tens of milliseconds, often slower).

If you use synchronous operations to get these resources then the processing thread is blocked until that IO completes.

Using asynchronous operations allows that same IIS thread to be used for something more useful while the IO completes. In higher load web sites this can be a significant scalability difference.