- 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
Measuring Performance
It's fairly easy to measure performance. We can use the application being tested or we can design an automatic benchmark and observe the original speed of the application against it. Then we can make changes to the software or hardware and determine if the execution time has improved. This is a very simple approach, but by far the most common metric we will use in our study.
It is important that, when measuring performance in this way, we identify the complete path of particular application operation. That is, we have to decompose it into its parts and assign values to each. Let us return to an earlier example, that of buying airline tickets online, and imagine that we're analyzing the performance of the "confirmation" process, which takes 2.8 seconds. Table 1–2 shows one possible set of results.
The way to read this table is to consider that completing the operation in the first (far left) column occurs at some point in time offset by the user's click (shown in the second column) and thus some percentage of time (shown in the third column) of the end-to-end execution. Some of this requires interpretation. For example, "Web server gets request" does not mean that the single act of getting of the request is responsible for over 6 percent of the execution time. It means that 6 percent of the execution time is spent between the initial user's click and the Web server's getting the request; thus, 6 percent was essentially required for one-way network communication. Building these kinds of tables is useful because it allows you to focus your efforts on the bottlenecks that count. For example, in Table 1–2, we can clearly see that the database query is the bottleneck.
To build accurate tables requires two important features. One is that your system be instrumented as much as possible; that is, all components should have logging
Table 1–2: Confirmation Process
|
Unit Action |
Elapsed Time of Action (ms) |
End-to-End Time (%) |
|
User clicks |
0 |
N/A |
|
Web server gets request |
170 |
6.07 |
|
Servlet gets request |
178 |
0.29 |
|
EJB server gets request |
1.68 |
|
|
Database query starts |
440 |
7.68 |
|
Database query ends |
2250 |
64.64 |
|
EJB server replies |
2280 |
1.07 |
|
Servlet replies |
2360 |
2.86 |
|
User gets information |
2800 |
15.71 |
features that allow them to be debugged or benchmarked. Web servers, become familiar with how these systems allow logging to be turned on and off. Make sure that you turn on logging for benchmark testing but turn it off when resuming deployment; if it's on, logging will slow down your application. Also, your code is actually the least likely place to be instrumented. Thus, it can be good to place some well-chosen logging statements in your code. For example, if an application server makes three queries (as part of a single transaction) before replying, it would be useful to put logging statements before each query.
The second important requirement is clock synchronization. The components being measured may be on different machines and without synchronizing your clocks, you can mistakenly assess too little or too much blame to an action that is actually much faster than you thought. Exact synchronization of clocks is a bit unrealistic, but as long as you know the clocks' relative drifts, you should be able to compensate in your calculations. Don't overdo synchronization or calibration—for example, being off by less than a hundred milliseconds for an entire operation is not a big deal because it won't be perceptible.