Actually instrumenting an application to compute this equation can be challenging. There are fairly simple tools available, like YSlow for the browser, www.websiteoptimization.com, PING, and others that can provide some values, like Payload, Bandwidth, RTT and AppTurns. But for server and client compute times, largely the only way to derive those values is to write code for them - adding in measurements within the application to log how long those portions of the equation are taking.

Once your application is instrumented, you need to start taking baseline measurements. What does good performance look like? What does bad performance look like? Under what conditions do these problems exist?

Now you start pressing against the difference between performance issues and scaling issues. A performance issue exists when a Web 2.0 application request takes too long with only a single user. A scaling issue exists when the single user performance is sufficient, but as the number of users increases, the performance degrades. The challenge here is that no one ever complains about scaling issues. You will never hear a user say, "The web site isn't scaling well." In reality, they say, "The site is too slow!" It is up to you to determine whether you have an actual performance issue or a scaling issue.

Looking at the performance equation, where do scaling issues turn up? Payload, round-trip time and appturns scale uniformly - they are normally the same regardless of the number of users. Bandwidth is rarely a problem; last time I looked, the Internet scales pretty well. Even client compute time scales fairly well, since the number of clients increases with scale.

Ultimately, scaling issues appear as server compute time. When those times rise with the number of users, you can be sure you're dealing with a scaling issue.

Strategies for Performance Tuning Web 2.0 Apps
Instrumentation only tells you where your performance problems are, it does not tell you how to solve them. The performance equation helps you focus on the actual issues and help measure the results of your efforts to improve things.

Perhaps you can see through the performance equation that a substantial portion of your performance problems has to do with round-trip time - you have so many resource files per request that a big chunk of the total response time is waiting for those files to arrive. Consolidating those files down should be an easy way to improve performance.

The same could be said for payload size or even bandwidth: there are relatively straightforward ways to improve these, such as compression for payload or simply buying more bandwidth.

But once you're digging into server compute time, you're dealing with a tougher nut to crack. Now comes the performance strategies of specialization and distribution.

With specialization, you break down your application into areas of specialization. This might be at the resource level, separating web page computation from static resource services. Moving your static resource files into dedicated hardware, whether your own or external, is one form of specialization.

Another specialization is isolating SSL services. You might have only a few pages in your application that require SSL; having dedicated hardware for that service lets the rest of the application avoid dealing with the computationally intensive aspects of SSL.

A key advantage of specialization is that it assists with instrumentation. Each specialization can be instrumented independently so that you have an even deeper view into where performance problems lie in your application.

Distribution is the performance technique most people think of - throw more hardware at it. The problem with distribution is that it doesn't provide uniform results. Doubling the amount of computing horsepower for an application does not double the number of users it can support. In fact, there is a progression of diminishing returns where adding more hardware will provide no benefit or even make the application go slower.

However, distribution is an effective strategy as long as it is implemented judiciously. The key is to use the strategy of specialization first to break down the various elements of the application so that each can be distributed independently of the other.

Another key challenge to distribution is affinity. Often Web 2.0 applications have singleton dependencies - places in the application that require a unique resource that has to remain centralized. This creates an affinity for a given user to a given server. One form of affinity is session data, the transitory needed to maintain state information about a given user's session while they are interacting with the application. If that session data is stored on the application server, that user is considered to be affinite to that server.

Affinity causes scaling problems because users cannot move freely from server to server as load increases. Moving session data to an independent data store removes that affinity and improves overall performance under scale.

Most people consider databases to be singletons, insisting that a given record be stored in one place once to maintain consistency. But in large-scale Web 2.0 applications, even databases can be distributed, separating reading from writing and partitioning data across multiple servers. One of the effects of this sort of distribution is latency - there's a delay between the time of adding a new record to the database and that data being visible to the rest of the system.

It's almost impossible to anticipate where performance problems will arise in a Web 2.0 application. It depends on how the application gets used and how often utilization changes from day to day. Deep instrumentation of your application can help you see where problems are and point you in the right direction to solve them.

Implementing specialization helps instrumentation be even more effective and simplifies distribution when more performance is needed. New techniques like virtualizaton and cloud computing ultimately benefit from instrumentation, specialization, and distribution as well. The techniques I've outlined in this article can be applied to these new technologies and others as Web 2.0 applications move into the enterprise.