Performance Testing is Hard
Our customers started complaining that one of our sites was slow. We attempted to verify on our own QA setup, then again on their production setup, and we couldn’t replicate. It turned out to be a browser-dependent performance problem, and further that, the same browser would behave radically different if compatibility mode was enabled.
Since we were an intranet application, compatibility mode was automatically forced on by default. Two weeks of research, one setting flip, instantly happier customers. Magic happens.
Performance profiling used to be very hard: it could be hardware or software dependent, or possibly bandwidth; now it’s gotten just downright impossible due to the wide disparities of JavaScript execution speed in the different browsers. As if making it render the same wasn’t hard enough.
Making Things Faster Tips
- Any 3rd party framework generates a mass of JavaScript to do cool things. This JavaScript will run slow in IE7. It will continue to run slow in IE8 unless you enable standards mode, which is disabled by default for intranet applications.
- Chrome and IE use XmlHttpRequests differently; IE seems to load in parallel, Chrome does not. This impacts debugging performance.
- ViewState isn’t a huge bitch on intranet applications. But it kills mobile, especially on upload. Use the new ASP.NET 4.0 features to disable that crap if you don’t need it.
- Look up Cache Busting. It helps amazingly to test cold-startup of web applications.
- Cold starts can be very rare. Don’t optimize the initial startup time if the application restarts very infrequently.
- Always check your logs to see what the actual load is. Just because a customer says it’s slow doesn’t mean the sites being hammered. LogParser is the best tool for handling IIS logs, hands down.
