c# - 我使用 IO 的所有操作都应该是异步的吗？

Question

当我阅读 MSDN 文章时 Using Asynchronous Methods in ASP.NET MVC 4 ，我得出结论，我应该始终对 I/O 绑定(bind)操作使用异步等待。

考虑以下代码，其中 movieManager 公开了像 Entity Framework 这样的 ORM 的异步方法。

public class MovieController : Controller
{
    // fields and constructors

    public async Task<ActionResult> Index()
    {
        var movies = await movieManager.listAsync();

        return View(movies);
    }

    public async Task<ActionResult> Details(int id)
    {
        var movie = await movieManager.FindAsync(id);

        return View(movie);
    }
}

1. 这是否总能给我带来更好的可扩展性和/或性能？
   • 我该如何衡量？
2. 为什么不在“现实世界”中使用它？
3. 上下文同步怎么样？
   • 我不应该在 ASP.NET MVC 中使用异步 I/O 有那么糟糕吗？

我知道这些问题很多，但有关该主题的文献得出的结论相互矛盾。有人说您应该始终对 I/O 相关的任务使用异步，也有人说您根本不应该在 ASP.NET 应用程序中使用异步。

Answer 1

Will this always give me better scalability and/or performance?

有可能。如果您只有一个数据库服务器作为后端，那么您的数据库可能是您的可扩展性瓶颈，在这种情况下，扩展您的 Web 服务器不会对更广泛的服务范围产生任何影响。

How can I measure this?

带有负载测试。如果你想要一个简单的概念验证，你可以查看 this gist of mine .

Why isn't this used in the "real world" a lot?

是的。 .NET 4.5 之前的异步请求处理程序编写起来非常痛苦，许多公司只是投入更多的硬件来解决这个问题。现在 .NET 4.5 和 async/await 获得了很大的发展势头，异步请求处理将继续变得更加普遍。

How about context synchronization?

它由 ASP.NET 为您处理。我有一个 async intro在我的博客上解释了 await 如何在您 await 任务时捕获当前的 SynchronizationContext 。在这种情况下，它是代表请求的 AspNetSynchronizationContext，因此 HttpContext.Current、文化等都会自动保存在 await 点.

Is it that bad, that I shouldn't use async I/O in ASP.NET MVC?

作为一般规则，如果您使用的是 .NET 4.5，则应该使用 async 来处理任何需要 I/O 的请求。如果请求很简单(即不访问数据库或调用其他服务)，则只需保持同步即可。