Response-time analysis did not originate from the firefighting world. It is from the infrastructure planning world of IT. The infrastructure community looks at IT as a network of services and conduits to those services. Translating this to DBA-speak, that would be a bunch of servers networked together. When a user makes a request, it is routed into the mystical IT cloud, where the request waits to be serviced and receives service from a potentially large number of service providers. One way to categorize this time is to place it into two buckets: time being serviced and time waiting to be serviced, or more simply, service time and queue time. Adding the two results gives you the response time. In the course of my Oracle forecasting and predictive analysis work, I noticed that response-time analysis could be applied to firefighting.

As I noted, this type of analysis deals with two high-level time categories: service time and queue time. From an abstracted performance analyst perspective, queue time contains all the time an Oracle process is waiting to be serviced. Service time is all the time the transaction is being serviced. Add all that time together, and you have how long it took for the database transaction to complete; that is, its response time. But it gets better! Since ORTA is used both when firefighting and forecasting, it can serve as a bridge between the two, allowing you to predict the effects of the solution. (Although this book does not focus on the predictive aspect of performance analysis, I will introduce the subject in Chapter 9.)

The response-time curve is fundamental to our work and is simple to understand. Take a look at the classic response-time curve graph shown in Figure 1-3. The vertical axis is the response time. For simplicity, think of how long it takes a query to complete. Keep in mind that response time is the sum of the service time and the queue time. The horizontal axis is the arrival rate. As more transactions enter the system, we shift to the right. Notice that when the arrival rate is small, the response time is equal to the service time; that is, there is no queuing. But as more transactions enter the system per unit of time (that is, the arrival rate increases), queuing will eventually occur. Notice that just a little queuing occurs near the beginning. But as the arrival rate continues to increase, at some point (usually around 75% utilization), the queue time becomes significant and eventually will skyrocket. When this occurs, the response time also skyrockets, performance slows, and users get extremely upset.