所有我使用IO的动作都是异步的？

在阅读MSDN第 Using Asynchronous Methods in ASP.NET MVC 4条时,我得出结论,我应该永远使用异步等待I / O绑定操作.

考虑下面的代码,其中movieManager公开了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);
    }
}

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

>我如何衡量这个？

>为什么这不用于“现实世界”？
>上下文同步怎么样？

>这是坏的,我不应该在ASP.NET MVC中使用异步I / O？

我知道这些都是很多问题,但有关这个话题的文献有相反的结论.有人说你应该总是使用异步的I / O依赖的任务,其他人说你不应该在ASP.NET应用程序中使用异步.

解决方法

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,它解释了在等待任务时等待着如何捕获当前的SynchronizationContext.在这种情况下,它是一个表示请求的AspNetSynchronizationContext,所以像HttpContext.Current,文化等等都会自动保存在等待点上.

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

作为一般规则,如果您使用的是.NET 4.5,则应使用异步来处理需要I / O的任何请求.如果请求很简单(即,不打到数据库或调用另一个服务),那么只需保持同步.

所有我使用IO的动作都是异步的？

解决方法

相关文章