Wednesday, March 20, 2013

Make Websites Startup Faster When Debugging

Currently I’m working on an website that caches data during the Application_Start event of the Global.asax.cs.  Generally this is a great idea for a website, especially when deploying a website in a load balanced environment, because the penalty of loading cached data can be spent in one page load.  Take the server out of the load balancer, deploy your changes, hit the first page, verify that no errors occurred, and put the server back in the balancer.  This ensures that a user hitting the site, won’t have to pay the penalty of loading the cache data.

But, this is not so much fun when developing/debugging.  90% of the time a developer works on a single page at a time, and if the page uses only a small fraction of the cache, or none at all, they get to pay the cache load penalty each time they restart the website.  Having to wait even 20 seconds each time the website is restarted in Visual Studio is real productivity killer.

Some developers may opt to comment out the cache loading portion of the Application_Start.  But if they accidently commit the change into source control, production could be affected the next time it’s deployed.  And the next time they get latest from source control, they’ll loose their local commented out Application_Start.   So how does one ensure that production will always cache the data on Application_Start, without forcing developers to pay the cache load penalty?

System.Diagnostics.Debugger.IsAttached to the Rescue!

protected void Application_Start(object sender, EventArgs e)
     if (System.Diagnostics.Debugger.IsAttached)
         // Speed up the first page load for debugging by not loading all of the Cache
Debugger.IsAttached will check to see if a debugger is currently attached.  Since this will always be the case when developing the website locally, and never be the case in production (assuming there isn’t some catastrophic production event), developers can enjoy the productivity improvements when developing the website, without risking any performance issues in production.

No comments: