异步已成为 .net 中的流行词,MS 已在 Web API 2 中引入它,以便可以处理更多请求,而其他请求则在等待 IO 完成。
虽然我可以看到这样做的好处,但这真的是一个问题吗?x64 架构的线程池中有 30000 多个线程,所以除非您的网站上有那么多并发用户,否则真的需要异步吗?即使您有这么多没有缓存的并发用户,我很确定 SQL Server 会因这么多请求而崩溃?
除了在 Web 框架上真正需要异步路由时它会发光吗?
异步已成为 .net 中的流行词,MS 已在 Web API 2 中引入它,以便可以处理更多请求,而其他请求则在等待 IO 完成。
虽然我可以看到这样做的好处,但这真的是一个问题吗?x64 架构的线程池中有 30000 多个线程,所以除非您的网站上有那么多并发用户,否则真的需要异步吗?即使您有这么多没有缓存的并发用户,我很确定 SQL Server 会因这么多请求而崩溃?
除了在 Web 框架上真正需要异步路由时它会发光吗?
这里的许多其他答案来自 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 更新)。
这里有一篇很棒的博客文章,它认为异步数据库调用不值得付出努力。重要的是要注意这篇文章中的假设:
async
越来越多的库提供异步 API(例如,实体框架)。服务器真正闪耀的地方async
是您的后端也可以扩展。例如,Web 服务、Azure SQL、NoSQL 集群等。示例:我正在编写一个 MVC/WebAPI 服务器,它使用 Azure SQL 和存储作为其后端(出于所有实际目的,我可以表现得像它们具有无限的可扩展性);在这种情况下,我将制作我的服务器async
。在这种情况下,您可以使用async
.
但是,如果您只有一个 SQL Server 后端(并且没有更改为 Azure SQL 的计划),那么创建您的 Web 服务器是没有意义的,async
因为无论如何您都会受到后端的限制。
你从哪里得到30000。我不记得确切,但我认为 Asp.net 使用 12 x 核心线程数。
当操作需要很长时间(上传、导出、处理)并且用户必须了解进度时,我必须使用异步。
在以下情况下您需要异步
1) 当你执行一个很长的操作并且你不想冻结你的 UI 时。
2)当你设计了一些需要在后台完成的任务时。
例如,您正在从数据库中渲染图像。但是你不希望你的页面在那个时候被冻结 async 真的很有帮助。