看stackoverflow大牛如何回答何时在ASP.NET中使用异步控制器？

转载自博客园：http://farb.cnblogs.com/

今天无意中看到stackoverflow上一个很好的问答，个人觉得很有价值，所以翻译过来和大家共享！希望大家能相互交流。

在ASP.NET MVC中何时使用异步控制器（Async Controllers）？

在ASP.NET MVC中使用异步操作的时候，我有这么几个关注点。异步操作何时提高我应用的性能，什么时候没改善？

1. 在ASP.NET MVC中到处使用异步操作真的好吗？
   
2. 对于可等待的（awaitable）方法： 当查询数据库时（通过EF/BHibernate/其他的ORM）应该使用async/await关键字吗？
3. 在一个单独的操作方法中，异步地查询数据库可以使用await关键字多少次？

当一个action必须执行多个独立的长期运行的操作时，异步action方法是很有用的。
假设我有三个操作，分别耗时500, 600和700毫秒。采用同步调用的话，总共的响应时间将会稍微超过1800毫秒。然而，如果是异步调用（并发），总共响应时间将会稍微超过700毫秒，因为那是最长的任务/操作的持续时间。

异步控制器类一个经典的用法是用于长期运行的Web服务调用。

数据库应该异步调用吗？

IIS线程池经常可能处理比一个数据库服务器更多的阻塞请求。如果数据库遇到了瓶颈，那么异步的调用并不会加速数据库的响应。由于没有限流机制，使用异步调用有效地分发更多的任务给一个不知所措的数据库服务器只会给数据库转移更多的负担。如果你的数据库遇到了瓶颈，异步调用不会是魔弹。

而且，异步并不意味着并发。异步执行释放了一个没有复杂度或性能损耗的外部资源阻塞的有价值的线程池线程。这意味着相同的IIS机器可以处理更多的并发请求，而不是它将运行的更快。

可以在MSDN上看一下这篇文章。作者花了很多精力在这篇博客上描述何时应该在ASP.NET中使用async而不是如何使用。

答标题问题：

首先，要理解async/await是释放线程的根本。在GUI应用中，主要释放GUI线程，因此用户体验更好。在服务器应用（包括ASP.NET MVC）中,主要释放请求线程，因此服务器可以扩展。

特别地，它不会：

让你的个人请求完成的更快。事实上，他们会完成的（只有一点点）更慢。当遇到一个await时，就会返回到调用者/浏览器。await只会向ASP.NET线程池“屈服”，而不是浏览器。

答问题1：

当你要进行I/O时，我可以说到处使用异步操作是好的。虽然它可能不一定是有益的（看下面）。

然而，对于CPU受限的方法使用异步操作是不好的。有时开发者认为通过在控制器中调用Task.Run可以获得async的好处，这是一个可怕的观点。因为那样的代码通过开启其他线程来结束释放该请求线程，因此根本没有受益（事实上，他们消耗了额外线程切换的开销）。

答问题2：

你可以使用你可利用的任何可等待的方法。如果你的ORM不支持async,那么不要尝试把它包装在Task.Run或者任何和那个相似的东西里。

注意我说的是“你可以使用”。如果你在讨论一个单数据库的ASP.NET MVC，那么（基本上确定）你不会从async获得任何伸缩性的好处。这是因为IIS可以比一个SQL Server（或者其他经典的RDBMS）的单一实例处理更多的并发请求。然而，如果你的后端是更现代的——SQL server集群， Azure SQL, NoSQL等等——你的后端可伸缩，并且伸缩性的瓶颈是IIS，那么你可以从async获得伸缩性的好处。

答问题3：

你爱用多少次就用多少次，只要你喜欢。然而，注意许多ORM都有“每次连接一次操作”的原则。特别的，EF每个DbContext只允许一个单独的操作；无论该操作是同步的还是异步的，这都成立。

而且，再次记住你后端的伸缩性。如果你碰上了一个单一实例的SQL Server,且IIS已经可以使SQL Server处于满负荷状态，那么SQL Server双倍或三倍的压力对你一点好处都没有。