In normal web-based applications, it's easier to know where the performance challenges lie. There are always major web pages that get the focus of our attention. They might be landing pages, the first place every user goes on the web site, or for particular areas of the web site, like a home page or a personalized portal page.

There are also pages that are computationally intensive - the page that completes a purchase, that submits a multi-page form, or that completes some major set of steps. These are all pages that naturally end up as focal points for performance tuning. But Web 2.0 applications, such as wikis, mashups, and other collaborative applications, behave differently.

Performance issues for Web 2.0 applications don't focus on specific pages, they focus on particular sets of data. For example, a new entry in the corporate wiki can generate a massive amount of work around that page, creating a performance problem. Another example could be a mashup of an application with a web front end bringing geospatial rendering to a mainframe-based data source. Suddenly the number of requests to the mainframe jumps a hundredfold, leading to a residual performance problem impacting users that aren't even involved in the Web 2.0 application.

Note that in both these examples, the actual issue here is a problem of scale, not performance per se. The application performed fine until a large number of users all wanted to access the same point at the same time.

The challenge of managing performance challenges in Web 2.0 application starts with instrumentation: you need to know where the performance problems lie. From there, you can start applying strategies and tactics to deal with the problem.

Instrumenting Web 2.0 Applications
The equation in Figure 1 is the Web Application Performance Equation, adopted from Sevcik and Wetzel's paper "Field Guide to Application Delivery Systems." This equation helps you break down the various elements in play when determining the performance of your Web 2.0 application.

Figure 1: The Web Application Performance Equation breaks down the various elements involved in the responsiveness of Web 2.0 Applications.

Breaking down the various elements:

• R: Response Time, the total time (in seconds or milliseconds if you're an optimist) that a given request takes. Notice the approximation symbol (≈) beside R admits that this equation is not perfect. The values here should represent the majority of the response time, but things are missing, like DNS requests, TCP/IP negotiation times, etc.
• Payload: The total number of bytes required to fulfill the request. For a typical web page this would include the HTML of the page, image files, CSS and JS files, etc. The payload of a web service request would contain only the header and XML document containing the data requested.
• Bandwidth: The bandwidth in bytes per second available for transferring data. The first part of this equation, Payload over Bandwidth, is often all that people evaluate when considering Web 2.0 application performance. Based on this thinking, minimizing the size of the payload and increasing the amount of bandwidth should improve performance. Often it has minimal benefit - there are other factors in play that affect performance far more.
• RTT: Round-Trip Time. This is the time it takes to communicate from the client end of the Web 2.0 application to the server end. It's typically measured in milliseconds, using tools like PING and TCP_PING. Round-trip times over LAN connections are typically 5-10ms. Once the Internet is involved, times can vary a great deal - within a city round-trip times can be 20-60ms. Across a country the times jump to 100ms, cross an ocean and it can rise to 300ms.
• AppTurns: The number of additional resources needed in a given request. For an HTML page, this is all of the image files, CSS and JS files, and so on. Modern web pages typically have 50-60 resource files associated with them. In a web services request, there are no additional AppTurns.
• Concurrent Requests: The number of requests a given web browser can handle at once. Internet Explorer 6 and 7 allows two requests to execute simultaneously, so two images can be downloaded at once. FireFox allows four requests and Internet Explorer 8 allows six. For a typical web page request, the first RTT in the equation accounts for the time to retrieve the page. Then the AppTurns and RTT over Concurrent Requests portion of the equation computes the time to retrieve the rest of the resource files. Presuming a 50ms round-trip time, 50 resource files and using IE7, you can expect 1.25 seconds just for round-trips - this does not account for the actual size of the files; that is handled in the payload section of the equation.
• Cs: Compute time on the Server. This is the processing time for rendering a web page, computing the web service request, etc. Time to retrieve data from databases, making out-of-process calls to external services, and so on are all covered under server compute time.
• Cc: Compute time on the Client. Finally, the last part of the equation adds in the time it takes the client to render the response. For a web page, this is the time to actually draw and compute the page. Other clients have similar rendering challenges. Compute time on the client is one of those secret costs of Web 2.0 applications, often forgotten about.