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 return; } PreloadCachedValues(); }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:
Post a Comment