- The Emergence of Web Applications
- Basic Definitions
- The Nature of the Web and Its Challenges
- Performance and Scalability
- Performance
- Scalability
- The Internet Medium
- Wide Audience
- Interactive
- Dynamic
- Always On
- Integrated
- Lack of Complete Control
- Measuring Performance and Scalability
- Measuring Performance
- Beyond Benchmarking
- Measuring Scalability
- Throughput and Price/Performance
- Scalability and Performance Hints
- Think End-to-End
- Scalability Doesn't Equal Performance
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Performance
Performance can be described simply as the raw speed of your application in terms of a single user. How long does a single application-level operation take? How long does it take to search for a book? How long does it take to confirm an online registration once we click Confirm? How long does it take to check out and pay at an online store? Notice that some of these examples describe atomic operations and some don't. When describing performance, we have to be clear if we are talking about one application operation or an entire session.
Consider the user interaction required to buy an airline ticket in Figure 1–2: In this session, there are three application operations, each consisting of a roundtrip between client and server. The operations are listed in Table 1–1 with their code names.
){kind=link}
Figure 1–2 Application operations associated with buying an airline ticket
When we are talking about the performance of an operation, such as selection, we are interested in the end-to-end time required to complete that operation. In other words, the clock starts ticking when the user clicks the button and stops ticking when the user sees the information delivered. Why all this focus on end-to-end performance?
Table 1–1: Application Operations
|
Code Name |
User Action |
Server Action |
|
Search |
Criteria specified |
Search based on criteria |
|
Selection |
Flight chosen |
Confirmation for that flight generated |
|
Confirmation |
Flight confirmed |
Confirmation processed |
We could, of course, judge performance by measuring the speed of the Web server's response, of the network, of our database retrievals, and so on. But we know that all of these performance marks are irrelevant when compared to the overall time for a logical operation. Although unit performance numbers make us happy or proud (especially if we designed that piece of the application!), end-to-end performance is the one that really counts—this is the metric that either scares users off or wins their loyalty. And thus, this is the one that can spell life or death for your application.
Addressing end-to-end performance means making operations faster for the user. To do that, we can improve the unit performance of some of the components involved in the operation(s). For example, we can improve the performance of the Web server, the database, or the application servers. The exact solution (e.g., better algorithms, more efficient queries, etc.) depends on the unit being tuned. The point is that measuring performance should be a top-down process: Start with the user, move to the components, and then to parts in the components. Look for trends and ask if a single instance of poor performance can be traced to a larger, general problem.