什么时候你真的需要在Web框架上异步？

Question

Async已成为.net中的流行语,MS已在Web API 2中引入它,以便可以处理更多请求,而其他请求则等待IO完成.

虽然我可以看到这样做的好处,但这真的是一个问题吗？x64架构在线程池中有30000多个线程,所以除非您的网站上有很多并发用户真的需要异步？即使你有很多没有缓存的并发用户,我也很确定SQL Server会因为那么多请求而崩溃？

除了它是否真的需要在Web框架上进行异步路由时才会闪亮？

Answer 1

这里的许多其他答案都来自UI(桌面/移动应用程序)的角度,而不是Web服务器的角度.

Async已成为.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启动足够的线程来处理它们之前.async保持你的线程免费(尽可能多),以便更好地处理爆发流量.

x64架构在线程池中有30000多个线程,所以除非您的网站上有很多并发用户真的需要异步？

当@Joshua指出你可能正在考虑一个请求队列限制(IIS队列默认为1000而ASP.NET请求限制为5000)时,@ Joshua再次正确.重要的是要注意,一旦填充此队列(在突发流量期间),新请求将被503拒绝.

即使你有很多没有缓存的并发用户,我也很确定SQL Server会因为那么多请求而崩溃？

啊,现在这完全是另一个问题.

我将在ThatConference 2013上专门针对async服务器进行演讲.谈话的一部分是async没有帮助的情况(我的Twitter更新).

这里有一篇很棒的博客文章,它采取了异步数据库调用不值得努力的立场.重要的是要注意这篇文章中的假设:

1. 在编写帖子时,异步Web服务器很难.这些天我们有async越来越多的库提供异步API(例如,实体框架).
2. 该体系结构假定单个Web服务器具有单个SQL Server后端.传统上这是一种非常常见的设置,但今天正在迅速改变.

当async服务器真正出色的是,当你的后台还可以扩展.例如,Web服务,Azure SQL,NoSQL集群等.示例:我正在编写一个MVC/WebAPI服务器,它使用Azure SQL和Storage作为其后端(出于所有实际目的,我可以表现得像它们具有无限的可伸缩性); 在那种情况下,我要打造我的服务器async.在这种情况下,您可以使用扩展服务器10倍或更多async.

但是,如果您只有一个SQL Server后端(并且没有计划更改为Azure SQL),那么制作您的Web服务器async是没有意义的,因为您无论如何都受到后端的限制.