CODEWITHSUNDEEP
c#.netasp.net-mvc-5async-await
user1625066
user1625066

Reputation:

Easiest way to make controller asynchronous

I inherited a large web application that uses MVC5 and C#. Some of our controllers make several slow database calls and I want to make them asynchronous in an effort to allow the worker threads to service other requests while waiting for the database calls to complete. I want to do this with the least amount of refactoring. Say I have the following controller

public string JsonData()
{
   var a = this.servicelayer.getA();
   var b = this.servicelayer.getB();
   return SerializeObject(new {a, b});
}

I have made the two expensive calls a, b asynchronous by leaving the service layer unchanged and rewriting the controller as

public async Task<string> JsonData()
{
   var task1 = Task<something>.Run(() => this.servicelayer.getA());
   var task2 = Task<somethingelse>.Run(() => this.servicelayer.getB());
   await Task.WhenAll(task1, task2);
   var a = await task1;
   var b = await task2;
   return SerializeObject(new {a, b});
}

The above code runs without any issues but I can't tell using Visual Studio if the worker threads are now available to service other requests or if using Task.Run() in a asp.net controller doesn't do what I think it does. Can anyone comment on the correctness of my code and if it can be improved in any way? Also, I read that using async in a controller has additional overhead and should be used only for long running code. What is the minimum criteria that I can use to decide if the controller needs async? I understand that every use case is different but wondering if there is a baseline that I can use as a starting point. 2 database calls? anything over 2 seconds to return?

Upvotes: 4

Views: 119

Answers (2)

i3arnon
i3arnon

Reputation: 116636

The only improvement the new code has is it runs both A and B concurrently and not one at a time. There's actually no real asynchrony in this code.

When you use Task.Run you are offloading work to be done on another thread, so basically you start 2 threads and release the current thread while awaiting both tasks (each of them running completely synchronously)

That means that the operation will finish faster (because of the parallelism) but will be using twice the threads and so will be less scalable.

What you do want to do is make sure all your operations are truly asynchronous. That will mean having a servicelayer.getAAsync() and servicelayer.getBAsync() so you could truly release the threads while IO is being processed:

public async Task<string> JsonData()
{
    return SerializeObject(new {await servicelayer.getAAsync(), await servicelayer.getBAsync()});
}

If you can't make sure your actual IO operations are truly async, it would be better to keep the old code.

More on why to avoid Task.Run: Task.Run Etiquette Examples: Don't Use Task.Run in the Implementation

Upvotes: 2

Stephen Cleary
Stephen Cleary

Reputation: 457302

The guideline is that you should use async whenever you have I/O. I.e., a database. The overhead is miniscule compared to any kind of I/O.

That said, blocking a thread pool thread via Task.Run is what I call "fake asynchrony". It's exactly what you don't want to do on ASP.NET.

Instead, start at your "lowest-level" code and make that truly asynchronous. E.g., EF6 supports asynchronous database queries. Then let the async code grow naturally from there towards your controller.

Upvotes: 6

Related Questions