为什么要使用异步控制器，当IIS已经处理请求并发？ [英] Why use async controllers, when IIS already handles the request concurrency?

问题描述

我不知道我为什么要费心使用控制器上的异步任务，当IIS已经处理了我的并发？

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

推荐答案

异步/地等待着asp.net是不是并发性，它是关于阻塞或不阻塞线程。

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

如果您使用异步/等待你释放线程，而你等待的操作。如果此操作是CPU密集型的，有没有好处（这将是稍微慢，因为上下文切换）

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)

如果该操作是IO绑定虽然（网络，磁盘，...）这意味着，IIS可以处理更多的并发请求，因为你不堵了什么都不做任何线程。

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.

这篇关于为什么要使用异步控制器，当IIS已经处理请求并发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！