Richard Campbell Blogs Too

You can thank Greg Hughes for this one - after our original show we got a ton of questions about backing up to disk. Steve Witner from Quantum came to our rescue with a great discussion about using disk-based backup alone and in conjunction with tape backup. We also dug into issues around data de-duplication to be more space-efficient.

This was our most asked for show, I hope you liked it. Send us an email at info@runasradio.com and let us know!

When we recorded show #3 with Dana Epp on Cardspace, we knew we had to bring him back for more. So now, three months later, Dana returns and we talk all server side. The server side story of CardSpace isn't as simple as the client side, but its important, and its only going to get better.

A couple of weeks ago I was in Calgary to do my SQL Querying presentation for the Calgary .NET Users Group. While there, John Bristowe interviewed me. That interview is now posted.

Actually, its really three separate interviews. The first starts off as a short history of my career in computers (30 years this August), how I got into .NET Rocks and RunAs Radio, speaking about SQL Server and my Querying Talk. After that we jumped into Strangeloop, what its about and where it came from. Finally, we ended up talking career advice... John asked me my thoughts on how developers can grow in their jobs.

I'd go on, but its probably best just to listen to the interview, its about a half hour long.

We had a great time talking to Charlie Russel, mostly because we dove into a real technical problem around Service Pack 2 for Windows 2003 R2. Love real time diagnostics. But somewhere along the way we remembered to dig into RemoteApp, the new feature in Windows Server 2008 for Terminal Services that allows applications to be accessed remotely as if they were running on the local machine.

As always, send us your thoughts at info@runasradio.com.

The last of our shows recorded at Tech Ed US 2007 in Orlando, Greg and I talked to Jeff Sigman about Network Access Protection. This is a cool new technology designed to limit exposure of your network to computers being plugged into the network - typically laptops.

Check it out, and then let us know what you think at info@runasradio.com.

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!