Richard Campbell Blogs Too

Blame Michele Leroux Bustamante for this one - she talked me into coming down to do a couple of presentations at the SoCal Code Camp.

I did my Querying Talk again, but also took The Scaling Habits of ASP.NET out for a spin for the first time since the Vancouver TechFest.

Scaling Habits is a fun talk for me because it really is a tour through the evolution of an ASP.NET application - from those early days where you're one guy with a clever idea for a web app, through to what it takes to run a large scale site with multiple servers and the related bureaucracy for operating it.

Along the way I talk about the elements of the evolving site - how much traffic is typical, the kinds of metrics that matter, and so on. And most importantly, what it takes to move to the next level of evolution for the application.

At the core of this whole concept is the idea of the Performance Equation.

A quick description of each factor in the performance equation:

Now I can't take credit for this equation, I did not invent it. The original one comes from the "Field Guide to Application Delivery Systems" by Peter Sevcik and Rebecca Wetzel from NetForecast. However, I did make one change to it - the original equation does not account for simultaneous downloading of resource files and the base overhead of the page file itself. That is represented by the separate addition of an RTT and dividing the rest of the AppTurns by the number of concurrent requests.

So all of these factors go into the time it takes for a web page to fully render on your web browser after you request it.

When I display the equation to an audience, I always ask the question: "What part do you work on?" When I'm talking to ASP.NET developers, invariably the answer is Cs - Compute time on the server. After all, that's the code you wrote. But if you don't know what Cs is in relation to all the other factors of the equation, how do you know if that's the right thing to work on?

Some other interesting issues I've run into once I started looking at web performance this way:

• In many cases bandwidth is just not the issue, we have lots. But when it *is* an issue, often we don't test with the same bandwidth that the customer has, so we don't realize when bandwidth is a problem.
• Round Trip Time is the ping time between the customer and the server. Again, since we often test with servers that are so close to us that the ping time is ultra-low, we don't have test conditions that match with our customers. Its amazing how huge a factor bad RTT can be for performance.
• AppTurns of course exacerbate RTT times, because its a multiplier - if you have a dozen JS files, a dozen CSS files and thirty images (which is remarkably common), you're talking about over 50 AppTurns, and even divided by Concurrent Requests, that expands response time by lots of seconds.
• Normally, with Internet Explorer and FireFox, the number of Concurrent Requests is four. It can be adjusted at the client computer, but its very rarely done. It is possible to do a trick with URI renaming where each resource appears to come from a separate server so that you can fool the web browsers into doing more than four concurrent requests.
• Compute time on the client becomes a significant issue when you get heavy with the Javascript, most often seen with AJAX-style pages. In my opinion, getting the browser more involved in generating a web page is a good idea, but you need to account for the cost involved. If you're only looking at server compute times, then of course AJAX looks like a brilliant solution - because you've hidden the cost.

Now that's not to say that Compute Time on the Server isn't important to the equation - it *might* be. But you should know for sure before you pour your time into improving it. Going through the exercise of breaking down where the total response time goes is a critical first step to making sure your effort is going to the right place.

Thanks again to all the folks at the SoCal Code Camp - I had a fantastic time, I'd love to come down again!