Elements of Response Time

There are many facets to achieving good response time. In order to achieve good response time:

• - The organization has to be using the right technology.
• - There has to be adequate capacity.
• - The workload passing through the system must be understood.
• - The data being processed must be understood.

But, having all these items in place is not enough. At the heart of success for achieving good response time is something called the “standard work unit.”

So what is response time? Fig. 7.2.1 shows the elements of response time.

Response time is the amount of time from the moment of the initiation of the transaction until the moment in time when the results of the transaction are returned to the end user. Fig. 7.2.1 shows that the transaction is initiated, the transaction is sent to the processor, the processor commences execution, the processor goes out and finds data, the data are processed, and the results are sent to the end user.

Typically, all of this activity occurs in a second or less. Given all the activity that takes place, it is a wonder that it occurs as fast as it does.

An Hourglass Analogy

In order to understand how good response time is achieved, it makes sense to study an hourglass.

Consider the hourglass shown in Fig. 7.2.2.

When you examine the flow of sand through the hourglass, the flow is steady and at an even pace. All things considered, the flow of sand is done efficiently.

So, how is the flow through the hourglass done in such an efficient manner? Consider the grains of sand as they pass through the center of the hourglass. Fig. 7.2.3 shows the flow of sand through the center of the hourglass.

One of the reasons (other than gravity) why the hourglass exhibits an even flow of sand is that the grains of sand are small and uniform in size. Consider what would happen if the hourglass was to have pebbles inserted in among the grains of sand.

Fig. 7.2.4 shows what happens if pebbles are inserted into the hourglass along with the grains of sand.

The result of placing pebbles in the hourglass is that the flow of sand is interrupted and the flow is erratic and inefficient.

In many ways, the transactions that run through an online system are like the grains of sand. As long as the transactions are small and uniform in size, the efficiency of the system is quite good. But when large transactions are mixed in with small transactions in the workload of an online transaction processing system, the flow is very mixed and inefficient.

And when the flow is inefficient, the result is poor response time.

The Racetrack Analogy

Another way to express the same thing is seen in Fig. 7.2.5.

In Fig. 7.2.5, a pathway with different workloads is pictured. You can think of it as a roadway where there are cars running. The cars are all fast and uniform in size. The speeds that are attained are quite high. The roadway could be the old Brickyard in Indianapolis or Daytona. The only cars running on the track are Porsches and Ferraris. Everything is running efficiently.

Now, consider another roadway. The next roadway is seen in Fig. 7.2.6.

In this roadway, there are some small fast cars and some semitrucks. This could be Mexico City at rush hour. Everything is slow.

The difference between the speeds that are attained is remarkable. On one track, there are very high rate of speeds. On another track, there are very low rates of speed that are attained. The major difference between the tracks is that large, slow vehicles are allowed onto the road. The large vehicles slow everything down.

Your Vehicle Runs as Fast as the Vehicle in Front of It

There is another way of thinking of the speeds that can be attained. That way is the vehicle you are in is as slow as the vehicle in front of you. And if the vehicle in front of you is a large, slow vehicle, then that is your optimal speed.

Stated differently, how fast can a Porsche run on a race track? The Porsche can run as fast as the slowest car in front of the Porsche.

The way then to achieve speed and efficiency in the online transaction environment is to allow only small fast-moving transactions into the system.

The size of an online transaction is measured in terms of how much data the transaction accesses and whether the transaction does update. The update a transaction does affects the amount of records that are locked during the update process. In general, an online DBMS “locks” records that might be updated while a transaction is in execution.

Fig. 7.2.7 shows what constitutes a “large” online transaction and a “small” online transaction.

The Standard Work Unit

The standard work unit then states “in order to achieve good and consistent online transaction time, each online transaction running in the system needs to be small and uniform in size.”

The SLA

Related to the standard work unit is the notion of a service-level agreement or SLA. An SLA is an agreement stating what amounts to an acceptable level of performance and service in the online transaction environment.

A typical SLA might look like the following:

• Mon–Fri, between the hours of 7:30 a.m. and 5:30 p.m.
  • All transactions will execute in no more than 3 seconds.
  • There will be no outages of greater than 5 minutes.

The SLA covers both average response time and system availability. The SLA covers only working hours. Outside working hours, the computer operation staff is free to do whatever is needed to be done to the computer—running large statistical programs, doing maintenance, running database utilities, and so forth.