Page 2 of 2   « previous page

The problem is that there's no view of the end objective - minimizing service time for the customer - and no collaboration across these groups focusing them beyond their individual server operations. In reality, the database bottlenecks are a direct result of the application procedure calls while the application responds to Web requests. All of these combine to have a direct impact on end-user service. Without the ability to track the flow of transactions across the multiple systems, each IT group can only try to optimize its own statistics, not of the response time to the customer.

4.  Finger Pointing
The real trouble starts when a cross-functional group assembles to try to respond to a customer-reported problem. With each department watching their own server-oriented statistics, the result is a "finger-pointing" session where blame is deflected from one group to the next.

Without a performance measurement system that identifies in exact detail the root cause of the performance bottleneck, finger pointing becomes inevitable. By contrast, by measuring end-user Wait-Time with the recommended detailed granularity, management can identify exactly where in the IT value chain the bottleneck lays and who is really responsible. Using Wait-Time techniques to pinpoint the source of the problem helps eliminate the finger pointing.

Key Requirements for Wait-Time Analysis
Wait-Time analysis is an approach to application performance management that captures and delivers data in a way that enables business decisions that have optimal service impact.

The foundations of Wait-Time analysis are three requirements - measuring User Requests, measuring Every Step, and measuring accumulated Time.

Requirement One: Every User Request - Individually
This requirement states that all IT performance statistics must correspond to specific user requests, not averages across the entire system. Individual SQL statements or Web user screens must be tracked individually as they pass through the respective servers. In a database or application server, mixing data across all requests has the effect of averaging all responses and hiding any unique information about the request of interest. To effectively identify the problem, each SQL or Java application screen must be monitored and optimized separately.(Figure 6)

Requirement Two: Every Step
To be actionable, every user request must be measured with sufficient granularity to identify each step taken along the path from the end user through the database. This requires more detail than simply designating the database layer as the source of delay. It requires measuring each of the individual processes along the execution path. For an Oracle or SQL Server database, these steps correspond to hundreds of individual Wait-Events. For a Web application, the steps can be Java methods that are executed on an application server. (Figure 7)

You can't take action if all you know is that your request waits on Java or Oracle. But if you know that your request is hung in a specific "getCreditCard.do" method or "Enqueue" database lock then you have sufficient detail to productively work the problem.

Requirement Three: Measure Time
The most important requirement is measuring the time spent on a request, not counting how often a computing resource was used. The principle follows logically from the business purpose of the information system, which is to process requests and deliver output as quickly as possible. Counting events provides no indicator of how long a database user must wait for a response, or how long a request must wait for the execution of a Java method. (Figure 8)

In the Wait-Time service-oriented performance approach, time is the most important resource to measure.

Conclusion: Practical Considerations for Wait-Time Analysis
The Wait-Time approach to performance monitoring described here is only practical if it can be implemented efficiently in a performance-sensitive production environment. While basic tools to extract Wait-Time from databases on an individual session basis were the first step in this type of analysis, more efficient approaches have now been developed that meet ease of use, low impact, and continuous monitoring requirements. Beyond the database, it's now possible to employ Wait-Time analysis efficiently in end-to-end production application environments.

With increased focus on service levels as the most important measure of IT productivity, Wait-Time analysis has come to the forefront as the monitoring technique that ties IT practice to overall IT goals. This movement is aided by the combination of superior results experienced by leading consultants and trainers as well as the availability of excellent packaged tools. Wait-Time analysis tells the IT organization exactly where the problem lies, who should fix it and how it impacts the customer. Unlike traditional methods that barely deliver clues, Wait-Time, implemented in sufficient detail, delivers answers.

Page 2 of 2   « previous page