-1

I have following request pipeline
enter image description here

Here,
A - Is a user who is accessing a MVC web application and clicks a button
B - Is a MVC controller (without any async/await) and makes a call to a GetDataAsync method of a rest api(C)
C - Is a rest api with async method named GetDataAsync
D - Is a database method call using entity framework and database calling method is async type.

With reference to the explanation on this link - https://learn.microsoft.com/en-us/archive/msdn-magazine/2014/october/async-programming-introduction-to-async-await-on-asp-net, when the threads are moved back to ThreadPool when the call is made for any I/O based operation, my questions are

  1. Is it the call at the point D in above pipeline which is resulting in thread being returned to the ThreadPool?
  2. If yes, it means the scalability of the rest-api is increased by making an async call to a I/O based operation, which in this case is database call i.e. D ?
  3. When the MVC controller makes an async call at point B, it is NOT contributing to scalability/performance of rest api, even if it is calling the async method of the api?
Tech Jay
  • 404
  • 1
  • 6
  • 16
  • 1
    This is so moot. Is B making an HTTP request to C? If so, then you have two separate processes and two separate threadpools and your question is not corret – zaitsman Sep 01 '20 at 12:54
  • B is making HTTP based call to C. – Tech Jay Sep 01 '20 at 13:12
  • Then this is a separate process, separate thread pool and separate scalability domain - and it depends whether this one is done async or not. – TomTom Sep 01 '20 at 19:34
  • @TomTom I understand that its separate process and threadpool for both the cases. The only point is that I want to understand is whether it is making the API methods async that makes it scalable or the async database call makes it scalable? – Tech Jay Sep 02 '20 at 10:59
  • API methods are not async unless they are async on the HTTP level (returning with come back later and a sync token). There is nothing on the network level that is different whether you make the call sync or async. – TomTom Sep 02 '20 at 11:00

1 Answers1

1

Assuming that your rest API is running as a separate app, something like this happens:

public class YourController : ControllerBase
{
    private readonly ISomeRepo _someRepo;

    public YourController(ISomeRepo someRepo)
    {
        _someRepo = someRepo;
    }

    [HttpGet("ExampleUrl")]
    public async ... GetDataAsync()
    {
       var data = await _someRepo.GetDataFromDbAsync(); // this is where async starts and thread may be returned to pool

       ...
    }
}

So I believe the answer to your first question should be: C

Question #2: Quote from link below, "For server applications, the primary benefit of async is scalability."

Question #3: If there is both an async and a sync version of same method in rest API, use of async method will improve scalability for rest API app. How client app makes the call, true async or with .GetAwaiter().GetResult(), does not matter for rest API app.

It is all about using a limited number of threads the best way.

There is a lot of good reading to choose from. Maybe start with this one: https://learn.microsoft.com/en-us/archive/msdn-magazine/2014/october/async-programming-introduction-to-async-await-on-asp-net

We are playing a little with parallel processing using async code in this question: https://stackoverflow.com/a/63692953/14072498

Roar S.
  • 8,103
  • 1
  • 15
  • 37
  • I think for the answer to first question should be D and not C. Even your line of code "await _someRepo.GetDataFromDbAsync();" suggests that it is during the async call to database that the thread is returned to thread pool.For your reply to question #3, if we are not making async database call, the thread would not be returned to thread pool. So it is the async database call that is making it scalable and not the async api method which makes it scalable. Correct me if I am missing anything – Tech Jay Sep 02 '20 at 10:52
  • @TechJay: If there will be no async calls in controller method, method is no longer async, and code will be executed sequentially on initial thread. When execution waits for result from sync db call, thread will do nothing (be blocked). But let's imagine that we replace db call with call to a service method that is using the same db method. In service method, there are one or more async calls before the db call. In this scenario, code after await in service method is candidate for running on a separate thread. Please see link above "We are playing a little ...". Async all the way is best. – Roar S. Sep 02 '20 at 11:27
  • so basically when we add any async DB or network call inside any API method, the API method releases the thread back to thread pool which in-turn increases the scalability. Same happens in the scenario that I have shared and code piece you have shared. The async DB call releases the thread back to thread pool and increases api scalability...correct? – Tech Jay Sep 06 '20 at 12:56
  • @TechJay; Instead of me trying to explain this further, I give you a link to this excellent answer: https://stackoverflow.com/a/37419845/14072498 – Roar S. Sep 06 '20 at 15:23