异步/等待和多层Web应用程序

Question

Because of some optimalization issues, i decided to rewrite controller's action method to asynchronous one. It is a multi-layer application, and since that, i'm facing an architecture problem, and i wonder what are the main differences between two approches I will show below. Let's say my synchronous method is:

public virtual ActionResult Method()
{
   SomeLogic.LargeOperation();
   return View(...);
}

LargeOpertation does a lot. Here's pseudocode:

public void LargeOpertion() {
   DatabaseManipulations1();
   IndependentWork();
   CallingToWebService1();
   IndependentWork();    
   DatabaseManipulations2();
   IndependentWork();
   CallingToWebService2();
   IndependentWork(); 
}

Each method inside LargeOperations has couple methods inside itself, and so on ... The question is: Do I need to make them all async and use await in almost every of application layer?

public virtual Task<ActionResult> Method()
{
   await SomeLogic.LargeOperation();
   return View(...);
}

public async Task LargeOpertion() {
   await DatabaseManipulations1();
   IndependentWork();
   await CallingToWebService1();
   IndependentWork();    
   await DatabaseManipulations2();
   IndependentWork();
   await CallingToWebService2();
   IndependentWork(); 
}

Or can I just use task on LargeOpertaion like that:

public virtual Task<ActionResult> Method()
{
   await Task.Run(() => SomeLogic.LargeOperation());
   return View(...);
}

Let's also assume that IndependentWork() is not so large.

Answer 1

Because of some optimalization issues, i decided to rewrite controller's action method to asynchronous one.

Before you start, you should realize what async will do for you and what it won't .

Asynchronous operations do not run faster. So, an asynchronous call to the database is not any faster than a synchronous call to the database.

await doesn't return to the browser early. All it does is release the current thread back to the ASP.NET threadpool.

So, each individual request still takes the same total amount of time (actually, just slightly longer , but not by a detectable amount).

What async does help with is scalability - that is, the ability of your application to handle more requests with the same resources. However, it only helps the scalability of your web app - it can't magically reach into your database and make that scale. So, if your scalability bottleneck is your database and not ASP.NET (which is usually the case), then async won't help you at all.

If your database backend is scalable (eg, NoSQL, Azure SQL, or a database cluster), and if your ASP.NET app needs to scale up, then you can benefit from async .

Do I need to make them all async and use await in almost every of application layer?

The best approach is to start at the "leaves" - the lowest-level methods - and work your way up from there. In this case, start at the database interaction and convert those to async first.

However, at no point should you use Task.Run or Task.Factory.StartNew . Instead, use true asynchronous APIs, such as the async support in EF6.