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