•   Pages are personalized and remember who the user is and what he or she did last, but users don't follow a predefined process.

•   Applications literally stitch pages together on-the-fly, generating the page in the user's browser from multiple sources. Instead of rendering pages via a single trip to a server, applications rely on content from multiple services that may reside on separate virtual or physical servers, which means multiple round trips between the browser and the various content sources. And because the dynamically generated content is dependent on the individual user, the frequency and order of those trips is highly unpredictable.

•   Popular content is apt to be viral, which means that the volume of traffic can jump exponentially with little warning. And the more features and user-generated content you have, the faster it can happen.

Creating an application that can deal with these characteristics for a known number of users is challenging enough. But if your site suddenly becomes hugely popular, the complexity of managing your application increases exponentially. Ultimately, having your application succeed beyond your expectations isn't a bad problem to have. The need for new features and the need to scale to accommodate unpredictable loads, however, put enormous demands on you and your application. You need an architecture that's agile enough to accommodate both growth and sudden surges.

Achieving such an architecture is no simple task. Page rendering in applications that incorporate user-generated content is substantially more complex than traditional data-driven Web applications. Additionally, in the race to deliver new features as quickly as possible, developers often turn to tools designed to accelerate development, many of which aren't optimized for performance at scale. When you combine more complex development processes with unpredictable use patterns and a rush to get applications to market as quickly as possible, programming for scalability inevitably takes a back seat.

Fundamentally, to ensure optimal performance even under extreme swings in demand, you need a system that can intelligently distribute load and lets you scale individual components of the application as needed. To achieve that, you need to be thinking about two key strategies: granular distribution and specialization.

Architecting More Granular Distribution
The traditional solution to increasing the scalability of an application has been basic distribution - throwing more hardware at the problem and distributing the application load among more servers. The problem with this strategy is that it's only effective if your entire application scales symmetrically, and in a Web 2.0 world, that's extremely unlikely. Your image demands may be rising much faster than your page computation demands, for example, but adding servers and having them all do the same work doesn't take that into account. What you need is a system that distributes intelligently at a more granular level - that's organized to scale individual components of the environment as needed. And that requires both a more intelligent approach to distribution and greater use of specialization.

The key to effective distribution is the ability not only to replicate servers but to manage all of those servers as a group. But the biggest impediment to doing that (and to responding dynamically to rapid changes in demand) is hidden resource affinities. The most common affinity is session, but there are a number of others in ASP.NET. Session affinity cripples the ability to distribute load between servers because a given user must always work (or "stick") with the same server where the session data resides. The theory of distribution is that you can double the number of users you can support by doubling the number of servers. An affinity, like session, undermines that behavior, so doubling the number of servers may only support 50% more users. Over time, that ratio continues to degrade until you get virtually no additional load support for additional servers.

As an application is developed developers focus primarily on features and performance and affinity issues rarely have a high priority. And as long as a relatively small number of users are using the application, they don't present a significant problem. When the application grows in popularity and requires more resources, however, these affinities can significantly impair the application's ability to scale. Ultimately, they can make it impossible to load balance effectively, undermining the entire distribution strategy.

To get rid of session affinity, you must move from an in-process session to out-of-process session. ASP.NET includes out-of-process options for handling session state. Without any additional application coding, you can configure the Web server to store session data in a separate database. However, developers typically avoid this solution because the additional processing tends to sap performance. The two extra trips across the internal network (reading session data from the database at the beginning of each session and writing session data at the end) makes an out-of-process session take as much as six times longer than an in-process session - a huge impact on overall application performance.

Fortunately, these out-of-process options aren't the only way to solve the session state affinity problem. One of the great things about ASP.NET is its broad support for third-party tools, components, and services. Session state management, in particular, uses a standard set of interfaces for storing and retrieving data, which means that many steps in the request processing pipeline can be handled by code from third-party vendors and solutions. This opens the door to third-party software and hardware products that address affinity.

Software solutions are available that provide distributed in-memory caching of session state and other workload data, partitioned across a Web server farm. There are also hardware solutions, such as the Strangeloop AS1000 Application Scaling Appliance, which centrally manages session state from an appliance. Because hardware solutions are deployed in-line, between the network load balancer and the application servers, they can manage session information out-of-process without a performance penalty. In Figure 1, you can see where the acceleration appliance sits in the Web farm, so that it can provide out-of-process session data while minimizing performance impact.

Specialization
Distributing load more intelligently is the first step to creating a more agile application, but a second, equally important, requirement is specialization. Fundamentally, specialization is the process of taking specific elements that the application reuses and isolating them from other elements. By doing that, you can distribute the workload more evenly and scale individual elements independently, as needed. Three immediate targets to consider for specialization are image handling, encryption, and caching.

IMAGES
Images are fundamentally different from the rest of an ASPX page and are handled by a different part of IIS entirely. So why put the additional load of image handling on servers that are primarily geared toward ASPX processing, when you can move them somewhere else? You can handle images with separate IIS servers inside your data center that are configured and optimized for image retrieval. You can also use third-party image services, such as Akamai, and take image processing out of your environment entirely.

Of course, distributing image management isn't without its challenges. It's code-intensive, and it can make the management of your application more complicated. When you're updating your site, for example, you have to update image servers as well as Web servers.