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

Question

当我阅读MSDN文章在ASP.NET MVC 4中使用异步方法时,我得出结论,我应该始终使用异步等待I/O绑定操作.

请考虑以下代码,其中movieManager公开ORM的异步方法,如Entity Framework.

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应用程序中使用async.

Answer 1

这会不会给我更好的可扩展性和/或性能？

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

我该怎么测量呢？

通过负载测试.如果你想要一个简单的概念验证,你可以查看我的这个要点.

为什么这个在"现实世界"中用得不多呢？

它是..NET 4.5之前的异步请求处理程序编写起来非常痛苦,很多公司只是在这个问题上投入了更多的硬件.现在.NET 4.5和async/ await正在获得大量动力,异步请求处理将继续变得更加普遍.

上下文同步怎么样？

它是由ASP.NET处理的.我在我的博客上有一个async介绍,解释了当你执行任务时如何await捕获当前.在这种情况下,它代表了请求,因此诸如文化之类的东西都会自动保存在各点之间.SynchronizationContextawaitAspNetSynchronizationContextHttpContext.Currentawait

是不是很糟糕,我不应该在ASP.NET MVC中使用异步I/O？

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