.Net Core Web Api Async Doesn't Matter?

Question

I've been writing my Web Api controller methods with the async keyword and have been using async all the way down. I've recently tried making a method sync to see how it would affect performance and was shocked to find that it has no blocking affect on any other http request.

Take examples-

[Route("Foo")]
class FooController {
  [HttpGet("Hello")]
  public string GetHello()
  {
    Thread.Sleep(100000); // 100 seconds
    return "Hello";
  }

  [HttpGet("Goodbye")]
  public string GetGoodbye()
  {
    return "Goodbye";
  }
}

With this I can run GET => /Foo/Hello followed by any number of GET => /Foo/Goodbye and there is no blocking on my requests to the Goodbye endpoint.

I originally thought that I'd be required to make the Hello method async so that requests to the Goodbye endpoint would return without delay. But making this method sync/async has no effect!

Very confused. Do Web Api applications not require async? Why is it recommended?

Answer 1

It's not that simple.

There is something called Thread pool. Each request to your application get assigned to a separate thread taken from the thread pool. This is the first reason why one request doesn't block the other.

Now, everything is well and good when you have low traffic so you're not hitting the limit number of threads in thread pool. But...

For the sake of discussion, let's say your request on average takes 1 second and that you have thread pool of size = 100. You will start experiencing throttling with the 101st request. That one, since it has no thread pool to be assigned to it, will have to wait for the 100th request to finish, release the thread back to thread pool and then it can get processed.

Now, depending on what your requests do, async can help (but can also cause problems, so don't use it blindly!):

1. If your request does I/O operations (network calls, file system, db async, etc..) then those operations work on I/O threads. Those don't come from thread pool. So, imagine a request that comes in and fires a network call or file read that takes 0.93sec. What that in effect means is that, if you don't use async, your thread pool thread is of no use for 0.93secs and it just sits there waiting for IO thread to finish. In those cases, async can be very useful because once it hits the await keyword (which is used with operations that use IO threads) it will release the thread from the thread pool immediately so that the next request can be served. Once IO operation completes, it will get a thread from the thread pool to serve the response.

2. If your requests don't use any IO operations but you force them to use async (there are ways to do it) then all you'll effectively be doing is swapping one thread pool thread (initial one used to take the request) for another one (that will take the operation to run). In that case, you'll just create overhead and lose performance.

But, anyways, I have a feeling that's not strictly related to your question. In any of the above 2 scenarios, your methods are ran in 2 separate requests and have pretty much nothing to do with async/await but with the server environment where requests are processed independently.