When you have your controllers either in ASP.NET MVC or Web API set up to (correctly) use async/await, the thread processing the request will be freed up and returned to the thread pool. As advertised by every online document.
In the book Professional IIS 7, I read that initially HTTP.sys handles the requests in kernel mode and if the threads are maxed out, queues them up (each app pool having its own queue IIRC).
Now, since IIS7 the pipeline is integrated (as compared to IIS6), does that mean that IIS and an application poop is technically the same entity (for the lack of a better word)? And when my application performs an async task, the thread returned to the tread pool technically frees up a thread to process another request for IIS as a whole (for that app pool)?
Or does IIS have its own limited amount of threads and is just a mediator between HTTP.sys and the app pools? So if for example I'm running 4 sites, each app pool capable of servicing 100 requests, but IIS itself not being able to mediate, say, more than 300 requests. In this case, I wouldn't gain anything by freeing up threads in my app pool, since IIS is bottlenecking the whole flow.