c# - 什么时候应该在 ASP.NET MVC 中使用异步 Controller ？

Question

我对在 ASP.NET MVC 中使用异步操作有一些顾虑。它何时会提高我的应用程序的性能，何时不会？

1. 在 ASP.NET MVC 中到处使用异步操作好吗？
2. 关于等待方法:当我想查询数据库(通过 EF/NHibernate/其他 ORM)时，我应该使用 async/await 关键字吗？
3. 我可以在一个单个操作方法中使用 await 关键字异步查询数据库多少次？

Answer 1

你可以找到我的 MSDN article on the subject helpful ;我在那篇文章中用了很多篇幅描述什么时候应该在 ASP.NET 上使用async，而不仅仅是如何使用async 在 ASP.NET 上。

I have some concerns using async actions in ASP.NET MVC. When it improves performance of my apps, and when - not.

首先，了解 async/await 都是为了释放线程。在 GUI 应用程序上，主要是释放 GUI 线程，以便用户体验更好。在服务器应用程序(包括 ASP.NET MVC)上，它主要是关于释放请求线程，以便服务器可以扩展。

特别是，它不会:

• 更快地完成您的个人请求。事实上，他们会完成(只是一点点)慢。
• 当您点击 await 时返回调用者/浏览器。 await 仅“让步”到 ASP.NET 线程池，而不是浏览器。

First question is - is it good to use async action everywhere in ASP.NET MVC?

我会说在任何进行 I/O 的地方都使用它是很好的。不过，它不一定有益(见下文)。

但是，将它用于 CPU 绑定(bind)方法是不好的。有时开发人员认为他们可以通过在 Controller 中调用 Task.Run 来获得 async 的好处，这是一个可怕的想法。因为该代码最终通过占用另一个线程来释放请求线程，所以根本没有任何好处(事实上，它们正在承担额外线程切换的代价)!

Shall I use async/await keywords when I want to query database (via EF/NHibernate/other ORM)?

您可以使用任何可用的可等待方法。现在大多数主要参与者都支持 async，但也有一些不支持。如果您的 ORM 不支持 async，则不要尝试将其包装在 Task.Run 或类似的东西中(见上文)。

请注意，我说的是“您可以使用”。如果您谈论的是具有单个数据库后端的 ASP.NET MVC，那么您(几乎可以肯定)不会从 async 中获得任何可伸缩性优势。这是因为 IIS 可以处理比 SQL Server(或其他经典 RDBMS)的单个实例多得多的并发请求。但是，如果您的后端更现代——SQL 服务器集群、Azure SQL、NoSQL 等——并且您的后端可以扩展，而您的可扩展性瓶颈是 IIS，那么您可以从 异步。

Third question - How many times I can use await keywords to query database asynchronously in ONE single action method?

想吃多少就吃多少。但是，请注意，许多 ORM 都有一个每个连接一个操作的规则。特别是，EF 只允许每个 DbContext 有一个操作；无论操作是同步的还是异步的，都是如此。

另外，请再次记住后端的可扩展性。如果您正在访问 SQL Server 的单个实例，并且您的 IIS 已经能够使 SQLServer 保持满负荷运行，那么将 SQLServer 的压力增加一倍或三倍对您根本没有帮助。