Until recently, tuning IT application performance has been largely a guessing game. This is both surprising and unacceptable considering the relentless focus IT organizations put on cost-efficiency and productivity.

The traditional approaches to database and application tuning that involve collecting large volumes of statistics and making trial-and-error changes are still in widespread use. Today, most server management and monitoring tools deliver "server-oriented" statistics that don't translate to concrete end-user benefits.

The landscape is changing, however. The current thinking of leading consultants, DBAs, and training organizations is focusing on performance tuning practices that are tied directly to end-user service levels and improvements in operating efficiency.

Wait-Time analysis is a new approach to application and database performance improvement that allows users to make tuning decisions based on the optimal service impact. Using the principles of Wait-Time analysis described here, DBAs, developers, and application owners can align their efforts with the service levels desired by their IT customers. Wait-Time analysis lets IT find the root cause of the most important problem impacting customers and identify which critical resource will resolve it.

What Is Wait-Time Analysis?
Measure Time
If you were trying to shorten your commute to work, what would you measure? Would you count the number of tire rotations? Would you measure the car's temperature? Would these statistics have any meaning in the context of your goal? All that really matters is what impacts the time for your trip. All the other statistics are distractions that don't help your mission. Wait-Time analysis gets to the root of the problem to achieve the end business result. Although this seems obvious, common IT practices suggest that other practices hold the answer. Rather than immediately focusing on the time to complete requested services, IT tools barrage the user with detailed statistics that count the number of many different operations. So while the DBA should really be looking at how long it took for the database to return the results of a query, typical tools display the number of input/output (I/O) operations and locks encountered. (Figure 1)

Get the Details
Under the trial-and-error approach, what level of detail do you need to actively improve your commute time? If the only statistic you have is that the trip took 40 minutes, you can compare one day to the next, but there's not enough data to help improve the situation. What you need is detailed insight into how long you spent at each stoplight, which stretches of road have the most stop-and-go traffic and how long you waited there. This detail is essential to making the exercise useful.

The same concept applies to IT performance systems. When Wait-Time is typically measured, a "black box" approach is taken, where the user sees how long a server took to respond to a request. However, no indication is given as to which of the thousands of steps performed by the server were actually responsible for the delay. As will be shown here, it's important not just to measure Wait-Time but to break it down into sufficient detail so that you can take action.

Wait-Time analysis for IT applications is the singular focus of measuring and improving the service time to the IT customers. By identifying exactly what contributes to longer service time, IT professionals can focus not on the thousands of available statistics, but on the most important bottlenecks that have direct and quantifiable impact on the IT customer.

Wait-Time Analysis for Service Level Management
Because Wait-Time analysis measures the collective time delays causing end users to wait for an information request, it's the measurement technique most closely matched to end-user service levels. For organizations focused on Service Level Management (SLM) techniques, or those bound by Service Level Agreements (SLAs), Wait-Time analysis techniques allow the IT department to measure the performance that is most relevant to achieving the stated service level goals. Service level management typically identifies technical metrics that define whether performance is adequate, and Wait-Time data is the basis for evaluating those metrics.

The Problem with Conventional Statistics
There are so many management tools gathering thousands of statistics from IT systems. Don't these provide the same answer as Wait-Time methods? Why are they not effective?

Traditional approaches to database tuning and performance analysis introduce the same errors identified in the driving example above.

1.  Event Counters versus Wait-Time Methods
Typical tools count the number of events, but don't measure time. These statistics are numerous and easy to capture, so they tend to flood management dashboards. But, are they useful?

Broad management dashboards have sophisticated displays of monitored data, but counting events or calculating ratios doesn't indicate or predict better performance for database customers. In fact, this approach can have the effect of covering up, rather than exposing, the real service level bottlenecks.

The example is an excerpt from a long summary of counted statistics. Clearly there's much detail and technical accuracy. But where would you go to begin your diagnosis? Do these raw numbers reveal a performance problem? Is the value for "physical writes direct" in the table too high or too low? There's no indication of impact on the end-user service level to make that judgment.

On the other hand, Figure 2 ranks individual SQL requests by Wait-Time. The statement with the highest Wait-Time is at the top of the list. Its relative impact on overall user service is reflected in the length of the bar - measuring how much time users experience waiting on this request. Without counting how many times an operation occurred, this is a much more meaningful measure of end-user service.

2.  System-Wide Averages
Typically statistics are gathered across an entire system, rather than on a basis that applies to an individual user request. When averaging performance across all requests, it becomes impossible to tell which requests are the most critical resource drains and which resources are impacting service levels.

Vendor-supplied database tools, for example, typically display data across the entire database without breaking it down into specific user requests. As a result, there's no indication which end-user functions were impacted.

3.  Silos versus End-to-End Analysis
Another key problem with typical IT monitoring tools is the creation of individual information "silos" that localize statistics for a single type of system, but don't expose an end-user's view of performance.

Because of the differing technical skill sets, separate groups manage databases, application servers, and Web infrastructure. Each group has a primary focus - to optimize the performance of their box. And typically they use the most common and convenient statistics to measure and improve performance. For an application server, this often means watching memory utilization, thread counts, and CPU utilization. For a database, this is a count of the number of sessions, number of reads, or number of processes.