问您什么时候真正需要在web框架上使用异步？

EN

这里的许多其他答案来自UI (桌面/移动应用程序)视角，而不是web服务器透视图。

异步已成为.net中的一个热门词，MS在Web 2中引入了异步，以便在其他人等待IO完成时，能够处理更多的请求。

async和await是在2012年的.NET 4.5 / VS中引入的。但是，ASP.NET从很久以前的.NET 2.0开始就具有异步请求功能。有人在用它。

async和await给表带来的是易于维护的异步代码。

虽然我可以看到这方面的好处，但这是否真的令人关注呢？

服务器上的async的主要优点是可伸缩性。简单地说，async任务的扩展要比线程好得多。

@约书亚的注释是内存的关键；线程占用大量内存(不要忘记不能分页的内核模式堆栈)，而async请求实际上只需要几百字节。

也有迫切需要考虑的问题。.NET线程池的注入速率有限，因此，除非您将minWorkerThread计数设置为比通常需要的值高得多的值，否则当您收到大量流量时，一些请求将在.NET能够旋转足够多的线程来处理它们之前达到503。async保持线程释放(尽可能多)，以便更好地处理突发的流量。

x64体系结构在线程池中有30000+线程，所以除非您的网站上有那么多并发用户，否则真的需要异步吗？

@约书亚指出，您可能在考虑请求队列限制( IIS队列默认为1000，ASP.NET请求限制为5000 )。重要的是要注意的是，一旦这个队列被填满(在突发的流量中)，新的请求就会被503拒绝。

即使您有那么多没有缓存的并发用户，我也非常肯定Server会对这么多请求掉以轻心？

那完全是另一个问题了。

我专门在2013年在ThatConference的演讲服务器上给出了一个async。讨论的一个部分是async不起作用的情况(我的推特更新)。

有一个优秀的博客帖子，它的立场是异步db调用根本不值得付出努力。重要的是要注意这篇文章中的假设：

1. 在撰写这篇文章时，异步web服务器是困难的。现在我们有了async，越来越多的库提供异步API(例如实体框架)。
2. 该体系结构假设一个带有单个server后端的web服务器。这是一个非常常见的设置传统，但正在迅速改变今天。

当您的后端也可以扩展时，async服务器真正闪亮的地方。例如，web服务、Azure SQL、NoSQL集群等等:我正在编写一个MVC/WebAPI服务器，它使用Azure和存储作为后端(出于所有实际目的，我可以使它们具有无限的可伸缩性)；在这种情况下，我将使我的服务器async。在这种情况下，您可以使用async扩展服务器10倍或更多。

但是，如果您只有一个Server后端(并且没有将其更改为Azure的计划)，那么就没有必要让您的web服务器async，因为您仍然受到后端的限制。

1. 当长操作可以有效地并行执行时。例如，您必须执行两个SQL并加载三个图片--以异步方式执行所有五个操作，并等待它们全部完成。在这种情况下，总的时间将是五个操作中最长的，而不是持续时间的总和。
2. 预取。如果你能(以很好的概率)预测用户会做什么(例如，几乎可以肯定，他会想看细节.)您可以开始准备下一页(框架，窗口)，而用户正在阅读前一页。

你从哪弄来的30000。我不太记得，但我认为Asp.net使用了12x的核心线程数。