Why async controller method is executing just like a sync method?

Question

I've created sample .NET Core WebApi application to test how async methods can increase the throughput. App is hosted on IIS 10.

Here is a code of my controller:

[HttpGet("sync")]
public IEnumerable<string> Get()
{
    return this.GetValues().Result;
}

[HttpGet("async")]
public async Task<IEnumerable<string>> GetAsync()
{
    return await this.GetValues();
}

[HttpGet("isresponding")]
public Task<bool> IsResponding()
{
    return Task.FromResult(true);
}

private async Task<IEnumerable<string>> GetValues()
{
    await Task.Delay(TimeSpan.FromSeconds(10)).ConfigureAwait(false);
    return new string[] { "value1", "value2" };
}

there are methods: Get() - to get result synchronously GetAsync() - to get result asynchronously. IsResponding() - to check that server can serve requests

Then I created sample console app, which creates 100 requests to sync and async method (no waiting for result) of the controller. Then I call method IsResponding() to check whether server is available.

Console app code is:

      using (var httpClient = new HttpClient())
      {
        var methodUrl = $"http://localhost:50001/api/values/{apiMethod}";
        Console.WriteLine($"Executing {methodUrl}");
        //var result1 = httpClient.GetAsync($"http://localhost:50001/api/values/{apiMethod}").Result.Content.ReadAsStringAsync().Result;

        Parallel.For(0, 100, ((i, state) =>
        {
          httpClient.GetAsync(methodUrl);
        }));

        var sw = Stopwatch.StartNew();
        var isAlive = httpClient.GetAsync($"http://localhost:50001/api/values/isresponding").Result.Content;
        Console.WriteLine($"{sw.Elapsed.TotalSeconds} sec.");

        Console.ReadKey();
      }

where {apiMethod} is "sync" or "async", depending on user input.

In both cases server is not responding for a long time (about 40 sec). I expexted that in async case server should continue serving requests fast, but it doesn't.

UPDATE 1: I've changed client code like this:

  Parallel.For(0, 10000, ((i, state) =>
  {
    var httpClient = new HttpClient();
    httpClient.GetAsync($"http://localhost:50001/api/values/{apiMethod}");
  }));

  using (var httpClient = new HttpClient())
  {
    var sw = Stopwatch.StartNew();
    // this method should evaluate fast when we called async version and should evaluate slowly when we called sync method (due to busy threads ThreadPool)
    var isAlive = httpClient.GetAsync($"http://localhost:50001/api/values/isresponding").Result.Content;
    Console.WriteLine($"{sw.Elapsed.TotalSeconds} sec.");
  }

and calling IsResponding() method executing for a very long time.

UPDATE 2 Yes, I know how async methods work. Yes, I know how to use HttpClient. It's just a sample to prove theory.

UPDATE 3 As it mentioned by StuartLC in one of the comments, IIS somehow throtling or blocking requests. When I started my WebApi as SelfHosted it started working as expected:

1. Executing time of "isresponsible" method after bunch of requests to ASYNC method is very fast, at about 0.02 sec.
2. Executing time of "isresponsible" method after bunch of requests to SYNC method is very slow, at about 35 sec.

Answer 1

You don't seem to understand async. It doesn't make the response return faster. The response cannot be returned until everything the action is doing is complete, async or not. If anything, async is actually slower, if only slightly, because there's additional overhead involved in asynchronous processing not necessary for synchronous processing.

What async does do is potentially allow the active thread servicing the request to be returned to the pool to service other requests. In other words, async is about scale, not performance. You'll only see benefits when your server is slammed with requests. Then, when incoming requests would normally have been queued sync, you'll process additional requests from some of the async tasks forfeiting their threads to the cause. Additionally, there is no guarantee that the thread will be freed at all. If the async task completes immediately or near immediately, the thread will be held, just as with sync.

EDIT

You should also realize that IIS Express is single-threaded. As such, it's not a good guage for performance tuning. If you're running 1000 simultaneous requests, 999 are instantly queued. Then, you're not doing any asynchronous work - just returning a completed task. As such, the thread will never be released, so there is literally no difference between sync and async in this scenario. Therefore, you're down to just how long it takes to process through the queue of 999 requests (plus your status check at the end). You might have better luck at teasing out a difference if you do something like:

await Task.Delay(500);

Instead of just return Task.FromResult. That way, there's actual idle time on the thread that may allow it to be returned to the pool.

Answer 2

IIS somehow throtling or blocking requests (as mentioned in one of the comments). When I started my WebApi as SelfHosted it started working as expected:

Executing time of isresponsible method after bunch of requests to ASYNC method is very fast, at about 0.02 sec. Executing time of isresponsible method after bunch of requests to SYNC method is very slow, at about 35 sec.

Answer 3

I'm not sure this will yield any major improvement, but you should call ConfigureAwait(false) on every awaitable in the server, including in GetAsync.

It should produce better use of the threads.