什么时候你真的需要在Web框架上异步？
Async已成为.net中的流行语，MS已在Web API 2中引入它，以便可以处理更多请求，而其他请求则等待IO完成。
虽然我可以看到它的好处，但这真的是一个问题吗？ x64架构在线程池中有30000多个线程，所以除非你的网站上有那么多并发用户真的需要异步？ 即使你有那么多没有缓存的并发用户，我也很确定SQL Server会因为那么多请求而崩溃？
除了它是否真的需要在Web框架上进行异步路由时才会shiny？
这里的许多其他答案都来自UI（桌面/移动应用程序）的角度，而不是Web服务器的角度。
Async已成为.net中的流行语，MS已在Web API 2中引入它，以便可以处理更多请求，而其他请求则等待IO完成。
async和await是在.NET 4.5 / VS 2012中引入的。但是，自从.NET 2.0以来，ASP.NET已经具有异步请求function – 很久以前。 并且有人使用它。
async和await带来的是异步代码，易于维护 。
虽然我可以看到它的好处，但这真的是一个问题吗？
async在服务器上的主要好处是可伸缩性。 简而言之， async任务比线程更好地扩展。
@Joshua的评论是关于记忆的关键; 一个线程占用大量内存（并且不要忘记无法分页的内核模式堆栈），而async请求实际上只占用几百个字节。
还有一些需要考虑的问题。 .NET线程池具有有限的注入速率，因此除非您将minWorkerThread计数设置为远高于通常需要的值，否则当您获得突发流量时，一些请求将会在.NET启动足够的线程来处理它们之前。 async使您的线程保持空闲（尽可能多），以便更好地处理突发流量。
x64架构在线程池中有30000多个线程，所以除非你的网站上有那么多并发用户真的需要异步？
当@Joshua指出你可能正在考虑一个请求队列限制（IIS队列默认为1000，ASP.NET请求限制为5000）时，@ Joshua再次正确。 重要的是要注意，一旦填充此队列（在突发流量期间），新请求将被503拒绝。
即使你有那么多没有缓存的并发用户，我也很确定SQL Server会因为那么多请求而崩溃？
啊，现在这完全是另一个问题。
我将在ThatConference 2013上专门针对async服务器进行演讲 。 谈话的一部分是async无助的情况（ 我的Twitter更新 ）。
这里有一篇很棒的博客文章 ，它认为异步数据库调用不值得付出努力。 重要的是要注意这篇文章中的假设：
- 在编写post时，异步Web服务器很难。 这些天我们有
async，越来越多的库提供异步API（例如，entity framework）。 - 该体系结构假定单个Web服务器具有单个SQL Server后端。 传统上这是一种非常常见的设置，但今天正在迅速改变。
async服务器真正闪耀的地方是你的后端也可以扩展。 例如，Web服务，Azure SQL，NoSQL集群等。示例：我正在编写一个MVC / WebAPI服务器，它使用Azure SQL和Storage作为其后端（出于所有实际目的，我可以表现得像它们具有无限的可伸缩性）; 在那种情况下，我将使我的服务器async 。 在这种情况下，您可以使用async将服务器扩展10倍或更多。
但是，如果您只有一个SQL Server后端（并且没有计划更改为Azure SQL），那么使您的Web服务器async是没有意义的，因为无论如何您都受到后端的限制。
- 长时间操作可以并行有效执行。 例如，您必须执行两个SQL并加载三个图片 – 将所有五个操作作为异步执行并等待它们全部。 在这种情况下，总时间将是五次操作的最长持续时间，而不是持续时间的总和 。
- 预取。 如果你可以预测（很有可能）用户会做什么（例如，几乎可以肯定，他会想看到细节……），你可以在用户阅读前一页时开始准备下一页（框架，窗口）。
你从哪里得到30000。 我不记得确切，但我认为Asp.net使用12 x内核线程。
我必须使用异步，当操作花费太长时间（上传，导出，处理）时，用户必须知道进度。
您需要在以下方案中进行异步
1）当您执行非常长的操作并且您不想冻结UI时。
2）当你设计一些需要在后台完成的任务时。
例如，您正在从数据库渲染图像。 但是你不希望你的页面被冻结，因为异步非常有用。