ASP.NET Scaling Chalk Talk at TechEd US#

I've been assembling my notes for my Chalk Talk on ASP.NET Scaling at TechEd US in Orlando.

The Chalk Talk will be held on Friday June 8 at 1pm, in the ASP.NET Community Area.

The biggest challenge in talking about scaling is to not fall into a discussion on performance. Most folks mix conversation about scaling and performance together, on the assumption that excellent performance provides excellent scaling. It isn't true - in some cases, to get great scalability, you have to impede performance. In reality, the best case scenario for scaling up an application is to maintain performance, not to improve it.

Performance is all about how quickly your web page responds to a request, scale is about how many requests you can handle at once. The "at once" part of that statement is important, since the idea that excellent performance provides excellent scale only is true when requests are not "at once", but fairly close together. If you could compute every page in 50ms and you only got requests every 100ms, you'd only be handling one request at a time... your great performance has given you the illusion of great scale. A lot of people consider this scaling, but its not really. Real scale is all about how your site handles simultaneous traffic.

There are two fundamental techniques for scaling: specialization and distribution.

Specialization is the process of separating out specific tasks that your web application does and building/buying specialized resources to handle those tasks better. You already do this - you have a separate database from your web servers. When you get into large scale web sites, image handling often becomes a specialization. You could set up dedicate image servers, or even offload that work to a third party company like Akamai. Getting the load of image handling out of your web servers allows them to handle more of the requests that they need to handle: Processing ASP.NET web pages. Obviously the challenge of making specialization work is going through every web page and altering the image tags so that they point at the image servers: Time consuming, but not especially hard. That's scaling by specialization.

The other technique for scaling is distribution. The key to distribution is creating multiple copies of the same resources and balancing work between them. Typically this would be multiple, identical web servers and a load balancer. The challenge to making distribution work well is effective load balancing, and that means a lack of affinity. That means no data specific to a given session kept in the web server, all of that information has to be available to every web server in the farm. There are a variety of affinite resources in ASP.NET, the best known of which is Session, and there are a variety of methods for making those resources non-affinite, the best known method being to write them to SQL Server.

This is where we get into the performance/scaling compromise: moving Session data out of the web server and over to SQL Server definitely slows down performance, in exchange for being much more scalable. But this is not a simple curve - sure, this method is slower per request on average, but that speed doesn't change for longer as the number of simultaneous requests increases.

Distribution also opens up advantages for reliability and maintainability, in exchange for dealing with the complexity of multiple servers. That's outside the scope of purely looking at scalability, but its certainly relevant to the equation over all. Its also important to remember that scalability isn't the only reason to have a web farm.

Of course, you can combine these two techniques, having specialized resources and distributing them across multiple servers. And this adds an additional advantage: You can scale each of those specialized resources independently. So if you need to improve the scalability of images, expand the image server farm.

The key to both these techniques is good instrumentation: You need to know where the problems are. Specialization helps because it creates clear boundaries between the various resources involved in a web application. And often you'll find that the non-affinity step you skipped becomes your key problem scaling up - and it will be instrumentation that will show that too you. Of course, then we get into the argument of whether or not the instrumentation *is* the problem, because it too exerts a certain amount of load on the servers.

There's more than just this to talk about as well: There are a variety of techniques for going to a non-affinity solution, there's also the challenges of caching at scale and invalidation.

And don't forget the database! As you scale up your web farm, the database can represent a serious bottleneck. Solving that is a huge task on its own, involving its own implementations around specialization and distribution.

I had originally suggested this topic as a breakout session, but I'm really looking forward to doing it as a Chalk Talk, for the higher level of interaction I expect to have with the audience. Chalk Talks are a lot more intimate, I'm going to steer clear of a slide deck and focus on using the white board to look at the various evolutions of a web application as it scales up.

Hope to see you there!

Friday, May 25, 2007 10:56:04 AM (Pacific Standard Time, UTC-08:00) #    Comments [0]  | 


Comments are closed.
All content © 2020, Richard Campbell
On this page
This site
<August 2020>
Blogroll OPML

Powered by: newtelligence dasBlog 1.9.7067.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Send mail to the author(s) E-mail

Theme design by Jelle Druyts

Pick a theme: