title: Thread management in asp.net core / kestrel
body: <p>I'm troubleshooting performance / scalability issues with an asp.net app we've migrated to asp.net core 2.0. Our app is hosted on azure as an app service, and is falling over far too easily with any moderate traffic.</p>
  
  <p>One thing that's puzzling me is how multiple concurrent requests are handled. From what <a href="https://stackoverflow.com/questions/40948857/is-kestrel-using-a-single-thread-for-processing-requests-like-node-js">I've read here</a>, Kestrel uses multiple event loops to handle your requests. But the actual user code is handled on the .net thread pool (<a href="https://github.com/aspnet/Home/issues/1371" rel="noreferrer">that's from here</a>).</p>
  
  <p>So, as an experiment - I've created a new asp.net core 2.0 MVC app, and added a rather nasty action method:</p>
  
  <pre><code>    [AllowAnonymous]
      public ActionResult Wait1()
      {
          System.Threading.Tasks.Task.Delay(1000).Wait();
          return new StatusCodeResult((int)HttpStatusCode.OK);
      }     
  </code></pre>
  
  <p>Now, when I push this to azure, I'd expect that if I send say 100 requests at the same time, then I <em>should</em> be OK, because 100 requests sounds like minor load, right? And the waiting will happen on the thread pool threads, right?</p>
  
  <p>So - I do just this and get some rather poor results - sample highlighted in red:</p>
  
  <p><a href="https://i.stack.imgur.com/zHBZ2.png" rel="noreferrer"><img src="https://i.stack.imgur.com/zHBZ2.png" alt="enter image description here"></a></p>
  
  <p>Hmm, not what I expected, about 50 seconds per request... If however I change the frequency so the requests are spaced a second apart, then the response time is fine - back to just over 1000ms as you'd expect. It seems if I go over 30 requests at the same time, it starts to suffer, which seems somewhat low to me.</p>
  
  <p>So - I realise that my nasty action method blocks, but I'd have expected it to block on a thread pool thread, and therefore be able to cope with more than my 30.</p>
  
  <p>Is this expected behaviour - and if so is it just a case of making sure that no IO-bound work is done without using async code?</p>