Why isn't async await improving performance? - asp.net-mvc

Question

I watched this video : https://channel9.msdn.com/Events/TechDays/Techdays-2012-the-Netherlands/2287. So i tried to implement the usage of async/await in a controller. SO this is basicaly what I did :
public class HomeController : Controller
{
private static WebClient _webClient = new WebClient();
public async Task<ActionResult> IndexAsync()
{
var data = await _webClient.DownloadStringTaskAsync("http://stackoverflow.com/");
return View("Index", (object)data);
}
public ActionResult Index()
{
var data = _webClient.DownloadString("http://stackoverflow.com/");
return View("Index", (object)data);
}
}
Then I used Apache Benchmark and did the two following tests :
ab -n 100 -c 100 http://localhost:53446/Home/index
and
ab -n 100 -c 100 http://localhost:53446/Home/indexasync
And I got the exact same performance (I have 8 CPU core). Why is that ?

Answer 1

Async is not about performance. That's just categorically incorrect. In fact, an async request will often be less performant that sync, simply because there's additional overhead involved with async.
The reason to use async is about efficient resource-management and scale. A typical web server process will have around 1000 threads. This is often called the "max requests", as one thread general equals one request. If you have an 8 core CPU, you should ideally have a process per core (in IIS those are called "web workers"). So, theoretically, you'd have around 8000 threads total to work with.
That's quite a lot actually, though a modern web page consumes more requests than most people think. The page itself is one request, but that page will have images and external JS and CSS files, all of which generate a request, and will often utilize AJAX, for further requests. The point is that while 8000+ threads is still quite a lot to have in your pool, you could still very well run out if the server is under significant load.
Async merely gives you breathing room above that limit. In situations where the thread enters a wait-state, it can be returned to the pool to field other requests while whatever external action is being completed. The alternative is that the thread would just sit there idle (sync). That's really all there is to it. It's entirely about tasking those otherwise idle threads with some other bit of work, which could mean the difference between requests queuing up and timing out or being handled, even if slowly.

Answer 2

Running a load test that exhausts the thread pool is difficult to do on a local box. It's a lot easier to pretend the thread pool is exhausted by artificially restricting it, as I do in my gist:
protected void Application_Start()
{
int workerThreads, ioThreads;
ThreadPool.GetMaxThreads(out workerThreads, out ioThreads);
ThreadPool.SetMaxThreads(Environment.ProcessorCount, ioThreads);
...
}

Answer 3

There are a couple of reasons that stand out.
From Using Asynchronous Methods in ASP.NET MVC 4
the number of threads in the thread pool is limited (the default maximum for .NET 4.5 is 5,000). In large applications with high concurrency of long-running requests, all available threads might be busy. This condition is known as thread starvation.
So, running 100 request at a time will not even begin to starve your threads.
Also, a simple GET request will run very quickly. A test that performs an action that takes multiple seconds or even minutes would bear more obvious performance gains.