当IIS已经处理请求并发时，为什么要使用异步控制器？

Question

我想知道为什么我应该在控制器上使用异步任务，当IIS已经为我处理并发时？

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

Answer 1

asp.net中的Async / await不是关于并发性，而是关于阻塞或不阻塞线程。

如果使用async / await，则在等待操作时释放线程。如果此操作受CPU限制，则没有任何好处（由于上下文切换，它甚至会稍微慢一些）

如果操作是IO绑定的（网络，磁盘，...），则意味着IIS可以处理更多并发请求，因为您没有阻止任何无效的线程。

Answer 2

正如其他人所指出的那样，async允许请求线程在进行异步操作时返回到线程池。使用同步处理程序，您的服务器最终会在I / O上阻塞线程，基本上没有任何重要但在它们被阻止时也无法用于其他请求。 async只是释放这些线程，以便它们始终有用。

所以，首先要注意的是问题＆＃34; async 或线程池＆＃34;这是错误的问题。使用async时，您允许ASP.NET最大限度地利用现有线程池。 async采用ASP.NET中的现有（并行）并发，并添加（异步）并发以实现更高的可伸缩性。

但问题仍然是＆＃34;为什么＆＃34;？原因有两个：async可以比（仅）线程池进一步扩展，async也更具响应性。正如在其他答案的评论中提到的，线程是非常重量级的对象，不必要地浪费;异步操作的内存远小于线程使用的内存。第二个原因也很重要：当突然发出请求时，线程池（自身）只能以有限的速率扩展; async使线程池能够更有效地处理突发请求。

Answer 3

处理请求时，您可能会访问可能需要大量时间的资源（例如，往返数据库的往返时间可能是几十毫秒，通常较慢）。

如果使用同步操作来获取这些资源，则处理线程将被阻止，直到IO完成。

使用异步操作允许在IO完成时将相同的IIS线程用于更有用的东西。在较高负载的网站中，这可能是一个显着的可扩展性差异。