Operational Analytics: Response Time
Abstract
At the heart of success in the operational environment is transaction response time. Transactions are at the heart of many businesses, and when the computer malfunctions, the business suffers. The journey a transaction has to take is a long journey through the computer. The single largest impediment to good performance is the I/O operation. When the I/O operation is executed, the computer operates at mechanical speeds, not electronic speeds. The effect of I/O on performance is especially important in the face of a program that has to do lots of I/Os. When one transaction in the job stream has to do lots of I/Os, queue time can result. When queue time becomes a factor, a transaction sits and waits in a queue until transactions in front of it execute.
Keywords
Transaction response time; I/O; Mechanical speed; Electronic speed; Performance; Queue time
Analytics can be used throughout the computing environment. Indeed, one of the values of even computerizing a system is to be able to do analytics.
One of the most important environments in corporate computing is that of the operational environment. The operational environment is one that is the place where detailed, up to the second decisions are made. The operational environment is used primarily by the clerical community. The operational environment is where the business of the corporation is transacted.
Fig. 11.1.1 shows that there are two primary processing and decision-making environments in most corporations. There is the operational environment, and there is the management decision environment.
There are several criteria that enhance the success of the operational environment. Some of those criteria include the following:
- • The ability to create, update, and delete individual transactions
- • The ability to have access to data
- • The ability to have integrity of transaction processing
- • The ability to handle large volumes of data
- • The ability to handle data systematically
- • The ability to execute quickly
Of all of these factors, the ability to access and process data quickly is the most important in operational systems.
Fig. 11.1.2 shows that performance—the ability to execute transactions quickly—is the most important criteria in the operational environment.
There are many reasons why performance—speed of execution—is so important in the operational environment. The main reason why performance is so important is that the computer has been integrated into the day-to-day business of the running of the corporation. When there is a problem with performance, the day-to-day business of the corporation grinds to a halt.
In order to understand the importance of speed of transaction execution, consider the following circumstances:
- • In a bank, a bank teller must wait 60 seconds for a transaction to process. The bank teller and the customer being served are both irritated.
- • In an airline reservation, the airline clerk must wait 60 seconds to conduct business across the network. Long queues of angry travelers build up waiting for the system to finish processing.
- • In an ATM environment, customers drive away—angry—when the ATM machine takes 60 seconds to complete a transaction.
- • On the Internet, when using a site, viewers go away when the site takes a long time in order to complete a transaction.
And there are many, many other circumstances where transaction response time affects the business of the corporation.
Fig. 11.1.3 shows that transaction response time is essential to the satisfactory running of the business.
Transaction Response Time
Transaction response time is the most important element of the operational environment. What then are the elements of response time? Fig. 11.1.4 shows the elements of transaction response time.
At step (1), a transaction is initiated. A customer wants to see how much is in his/her account. A shelf stocker wants to place an item on the shelf of a store. A clerk wants to mark the successful manufacture of an order. An airline wants to upgrade a customer. These are all forms of initiating a transaction.
At step (2), the transaction arrives at the computer. The program goes into execution. Variables are initialized. Calculations are made. Algorithms are executed. Then, somewhere along the line of doing its processing, the computer program discovers that it needs to go to a database and find some data in order to execute.
At step (3), a request is made to the DBMS in order to find data. The DBMS honors the request and goes off to search for some data. Upon finding the data, the DBMS packages the data and sends it back to the computer.
The program commences processing again. The program discovers that it needs more data so the program issues another request for data to the DBMS. Data are returned to the program.
Finally, upon conclusion of the program—at step (4)—the program inside the computer is ready to return results to the user making the request.
The results are returned to the user at step (5).
Response time inside the computer is measured from the length of time it takes for steps (2), (3), and (4) to execute. On the average response, time is typically between 1 and 2 seconds. Given all the computer had to go through, it is amazing that response time is as fast as it is.
Fig. 11.1.5 shows how response time is measured.
Far and away, the biggest element of response time (i.e., steps (2), (3), and (4)) is the amount of time needed to search for and retrieve data. The processing inside the computer—steps (2) and (4)—occurs very quickly. It is step (3) that chews up the most amount of time.
There is a term for step (3). That term is an “I/O” operation (or an “input/output” operation). An I/O refers to the work done by the system in making either an input or an output to the database managed by the system.
Fig. 11.1.6 depicts an I/O operation.
There are two kinds of speeds found in a computer—electronic speeds and mechanical speeds. Electronic speeds are measured typically in nanoseconds. Mechanical speeds are measured in terms of milliseconds. The difference in speeds is akin to flying on a jet airplane and riding a bicycle. There is that much difference between the two types of speeds.
The internal operations of a computer operate in electronic speeds. The I/O operations of reading or writing to the database operate at mechanical speeds.
In order to get a program to operate quickly, the analyst needs to minimize the number of I/Os that are being done.
Minimizing the number of I/Os being done has the effect of speeding a program in its execution. But minimizing I/Os also has the effect of reducing the speed of every other transaction that is awaiting execution.
In a computer, a single program executes one at a time. The other programs that need to execute wait while the one program that is in execution finishes. The time the other programs have to wait is called “queue” time.
Fig. 11.1.7 illustrates queue time.
There are two primary ways that queue time can build inside a computer—either a single program takes a long time to execute or the rate at which transactions arrive at the queue exceeds the average execution time.
In any case in many computers, it is queue time that significantly causes slowdowns in processing.
Another way of looking at the phenomenon of performance is in terms of the number of I/Os being done by a transaction.
Fig. 11.1.8 shows two different kinds of transactions.
The transaction on the top is not going to be a fast-running transaction. It has too many I/Os that it has to do. The transaction on the bottom has a much better chance of being a fast-running transaction. It has only 1 or 2 I/Os that it must do.
Therefore, looking at the number of I/Os that a transaction must do is a good way to look at the performance characteristics of a transaction.
There is a way to reduce the amount of I/Os that a transaction has to do.
Consider the transaction shown in Fig. 11.1.9.
In Fig. 11.1.9, it is seen that lots of different kinds of data are needed in order to execute the transaction. If the transaction goes and looks on disk storage for all the different places where the data reside, the transaction will not be a fast-running transaction.
What the database designer could do is to combine all or some of the data into a single database design. There is nothing that says that data of different types must be placed in different databases. In order to enhance performance, the analyst could combine all the data (or even some of the data) into a single database.
This type of design is referred to as a “denormalized” design. Fig. 11.1.10 shows that data can be denormalized.
Once the data are denormalized, the number of I/Os needed to execute the transaction is reduced. The transaction now becomes a fast-running transaction.
Every now and then, it happens that a transaction needs to look at a lot of data, regardless of how the data are organized. Such programs are typical of report programs that look at the day's activities or the month's activities.
Fig. 11.1.11 shows one of these long-running programs.
What happens if one of these long-running programs is mixed with a lot of short-running programs, as seen in Fig. 11.1.12?
The answer is performance for the entire system comes to a halt. The minute the long-running program goes into execution, the queue builds behind the long-running program. And that defeats the purpose of the operational environment.
So what can the analyst do if it is necessary to run a long-running program (which is a fact of life)?
Fig. 11.1.13 shows some solutions to allowing the system to run long-running programs and to have online transaction response time.
One solution to resolving the conflict between long-running programs and the need for consistent response time is to partition off the time slots for running on the computer. All fast-running transactions run during the daytime when business needs for there to be good response time, and long-running programs are able to be executed in the wee hours of the morning, when no one else is using the machine.
An alternative is to execute long-running programs on a different machine on a different DBMS than the database and machine that the transactions are operating on. This alternative works whenever there is no need for the long-running program to access the actual data that are being transacted against.