我们如何通过在 asp.net MVC 6 中实现异步控制器来实现性能？答案

【问题标题】：How we can achieve performance by implementing async controller in asp.net MVC 6?我们如何通过在 asp.net MVC 6 中实现异步控制器来实现性能？
【发布时间】：2015-08-05 17:30:55
【问题描述】：

什么时候最好在 ASP.NET MVC 中使用异步控制器。

是否涉及任何编码或性能成本？

MSDN 建议将它用于长时间运行的进程，但我只是想知道如果我们将它用作普通控制器的完全替代品是否有益？

我们计划将 WCF 服务与我们的控制器方法一起使用。

【问题讨论】：

标签： c# asp.net-mvc wcf asp.net-mvc-4 model-view-controller

【解决方案1】：

首先，异步不是“性能”的同义词。事实上，使用异步实际上会降低性能，因为异步涉及的开销非常大。

异步所做所做的是在线程处于等待状态时将线程释放回池中。这意味着您的网络服务器在耗尽其“最大请求数”之前被赋予了更高的阈值，或者换句话说，没有空闲线程来处理新请求。

在同步请求中，线程被整个请求占用。如果涉及一段时间的等待（来自 API 调用的网络延迟等），即使实际上没有完成任何工作，它也会保留该线程。如果您同时收到 1000 个请求（典型的网络服务器开箱即用的最大请求数），那么每个进一步的请求都会排队，直到前 1000 个线程的一个请求返回到池中。

在异步请求中，一旦线程正在等待某件事发生（即不工作），它就会返回到池中，即使它所服务的原始请求尚未完成。这允许为新请求提供服务。当放弃线程的原始任务完成时，会从池中请求一个新线程以继续为该请求提供服务。这有效地为您的服务器在负载下提供了一点喘息空间。除此之外，async 什么都不做，至少在 Web 服务器提供请求的上下文中是这样。

一般来说，建议使用异步，因为即使它提供的那一点喘息空间也可能意味着您的服务器处理负载或崩溃之间的差异。但是，您应该衡量您对 async 的使用，以确保您实际上购买的东西值得它增加的开销。例如，MVC 6 允许您执行诸如异步渲染部分内容之类的操作。但是，如果您的服务器配备了企业级 15,000 RPM 硬盘驱动器或 SSD，那么等待线程所经历的时间可能非常短，以至于来回传递线程实际上比操作本身需要更多时间, 同步运行。

【讨论】：

【解决方案2】：

我想说这篇文章很好地涵盖了这个主题： When should I use Async Controllers in ASP.NET MVC?

我的观点是，当您在其中调用异步方法（如 I/O 操作）时使用异步操作是好的，当您在内部没有任何异步调用的情况下进行异步操作时，它并不是特别糟糕，但是：

你会有一个不必要的线程切换，不会有很大的性能损失，但也不是很好
VS 会警告您，异步操作中没有等待，这可能导致不必要的 Task.Run 调用

【讨论】：