title: Why use async requests instead of using a larger threadpool?
body: <p>During the Techdays here in the Netherlands Steve Sanderson gave a presentation about <a href="http://channel9.msdn.com/Events/TechDays/Techdays-2012-the-Netherlands/2287"><em>C#5, ASP.NET MVC 4, and asynchronous Web</em>.</a> </p>
  
  <p>He explained that when requests take a long time to finish, all the threads from the threadpool become busy and new requests have to wait. The server can't handle the load and everything slows down.</p>
  
  <p>He then showed how the use of async webrequests improves performance because the work is then delegated to another thread and the threadpool can respond quickly to new incoming requests. He even demoed this and showed that 50 concurrent requests first took 50 * 1s but with the async behavior in place only 1,2 s in total.</p>
  
  <p>But after seeing this I still have some questions.</p>
  
  <ol>
  <li><p><strong>Why can't we just use a bigger threadpool? Isn't using async/await to bring up another thread slower then just increasing the threadpool from the start? It's not like the server we run on suddenly get more threads or something?</strong> </p></li>
  <li><p><strong>The request from the user is still waiting for the async thread to finish. If the thread from the pool is doing something else, how is the 'UI' thread kept busy? Steve mentioned something about 'a smart kernel that knows when something is finished'. How does this work?</strong></p></li>
  </ol>