IActionResult or async Task<IActionResult> what are the advantages?

Question

We're going to create a new API in dotnet core 2.1, this Web API will be a high traffic/transactions like 10,000 per minute or higher. I usually create my API like below.

[HttpGet("some")]
public IActionResult SomeTask(int id)
{
   var result = _repository.GetData(id)
   return Ok(result);
}

If we implement our Web API like below, what would be the beneficial?

[HttpGet("some")]
public async Task<IActionResult> SomeTask(int id)
{
    await result = _repository.GetData(id);
    return Ok(result);
}

We're also going to use the EF core for this new API, should we use the EF async as well if we do the async Task

Answer 1

What you're really asking is the difference between sync and async. In very basic terms, async allows the possibility of a thread switch, i.e. work begins on one thread, but finishes on another, whereas sync holds onto the same thread.

That in itself doesn't really mean much without the context of what's happening in a particular application. In the case of a web application, you have a thread pool. The thread pool is generally comprised of a 1000 threads, as that's the typical default across web servers. That number can be less or more; it's not really important to this discussion. Though, it is important to note that there is a very real physical limit to the maximum number of threads in a pool. Since each one consumes some amount of system resources.

This thread pool, then, is often also referred to as the "max requests", since generally speaking one request = one thread. Therefore, if you have a thread pool of 1000, you can theoretically serve 1000 simultaneous requests. Anything over that gets queued and will be handled once one of the threads is made available. That is where async comes in.

Async work is pretty much I/O work: querying a database, read/writing to a file system, making a request to another service, such as an API, etc. With all of those, there's generally some period of idle time. For example, with a database query, you make the query, and then you wait. It takes some amount of time for the query to make it to the database server, for the database server to process it and generate the result set, and then for the database server to send the result back. Async allows the active thread to be returned to the pool during such periods, where it can then service other requests. As such, assuming you have an action like this that is making a database query, if it was sync and you received 1001 simultaneous requests to that action, the first 1000 would begin processing and the last one would be queued. That last request could not be handled until one of the other 1000 completely finished. Whereas, with async, as soon as one of the thousand handed off the query to the database server, it could be returned to the thread pool to handle that waiting request.

This is all a little high level. In actuality, there's a lot that goes into this and it's really not so simple. Async doesn't guarantee that the thread will be released. Certain work, particular CPU-bound work, can never be async, so even if you do it in an async method, it runs as if it was sync. However, generally speaking, async will handle more requests than sync in a scenario where your thread-starved. It does come at a cost though. That extra work of switching between threads adds some amount of overhead, even if it's miniscule, so async will almost invariably be slower than sync, even if only by nanoseconds. However, async is about scale, not performance, and the performance hit is generally an acceptable trade for the increased ability to scale.