title: ASP.Net - Presence of Global.asax Prevents Parallel Request Execution?
body: <p>Hedge - this could end up being a 'dumb newbie' question, but if not it could be one of the more interesting posts today.</p>
  
  <p>Basically, I'm seeing that merely adding a Global.asax component to a web application causes the runtime to execute page requests serially, whereas web applications without a Global.asax process requests in parallel as expected.  Impact would be that scalability goes out the window if you use Global.asax - I'm skeptical that's actually the case but am currently blocked on any better explanation.</p>
  
  <p>Here's the scenario:</p>
  
  <ol>
  <li>Create a new blank web application.</li>
  <li><p>Add a page that takes 5 seconds or so to complete.  I used the below but the exact method of delay doesn't seem to matter:</p>
  
  <p>DateTime PageStartTime = DateTime.Now;</p>
  
  <p>while (DateTime.Now &lt; PageStartTime.AddMilliseconds(5000)) { System.Threading.Thread.Sleep(0); }</p></li>
  <li><p>Add another page to use as a utility to reset the app domain.  This isn't strictly necessary to see the problem behavior but is helpful in repeating the tests:</p>
  
  <p>HttpRuntime.UnloadAppDomain();</p></li>
  <li><p>After building, start a browser with one tab (or window) for the app domain reset, and 3 tabs (or windows) for the long-running page.</p></li>
  <li><p>F5 the 'reset' page, wait a sec, then F5 the 3 'delay page' tabs.  You'll see that (as expected) the 3 pages end about the same time, i.e. that they're clearly running in parallel.  Run all the F5's you want and they'll still parallel as expected, presumably until the cows come home.</p></li>
  <li><p>Back to the project, add a 'Global Application Class' (Gloabl.asax) component.  No need to add any code - mere presence of the component is the test basis.</p></li>
  <li><p>After building, return to browser and quickly F5 the 4 tabs.  Again, the long-running pages parallel as expected, at least if you hit the 3 tabs fairly quickly.  Now for the good part - wait a sec until all complete, then (without using the reset tab) F5 the 3 'delay' pages again - you'll see that:</p>
  
  <p>a. The total time for all 3 to run is about 15 seconds - 3 times longer than expected.  The pages appear to be processed serially, i.e. one after the other.</p>
  
  <p>b. The order of completion for the second and third tabs is random, suggesting that ASP hasn't even decided which should run first until after the first request has completed.</p>
  
  <p>c. If you reset (unload) the app domain, you get another chance to have the pages parallel, but after they complete that first cycle they go right back to serial execution.</p></li>
  <li><p>Back to the project, remove the Global.asax component, build, and retest - the page requests again parallel as expected for the long-haul.</p></li>
  </ol>
  
  <p>Cool, eh?</p>
  
  <p>Stuff I tried:</p>
  
  <ol>
  <li>Various .Net versions - 3.5 and 4,</li>
  <li>Various web servers - WebDev, UltiDev, IIS,</li>
  <li>Different ways of delaying the page - real work, with and without yield, etc,</li>
  <li>Browser usage - one browser window with multiple tabs, versus dedicated browser windows,</li>
  <li>Code placement - tried both page 'Load' and 'PreRender' events for delay code,
  ~. Other stuff now rolled off of gray-haired memory...</li>
  </ol>
  
  <p>Clearly the above isn't a representative or useful project, but I stumbled on this doing something that has both intentionally long-running pages and an actual need for Global.asax - mainly for global static variables.  I imagine most 'normal' web apps would run fast enough that few would notice if they reverted to sequential request execution, but this behavior sure broke mine - been hammering this for three days so any ideas most appreciated!</p>
  
  <p>Thanks,
  David</p>