考虑下面的代码,其中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的任何请求.如果请求很简单(即,不打到数据库或调用另一个服务),那么只需保持同步.
