Response-time Essay

On the face of it, the concept of response time is simple and intuitive. Each of us turns to a computer or terminal device from time to time as a tool or toy to use in the course of our daily activities. In general, each individual key or mouse button press results in some sort of change in the display presented to us. These changes are what we mean by responses, and the time that elapses between the input and the response is called the response time.

One of the challenges in analysis of response time is the fact that some of the inputs require the desktop computer to do very little, and consequently are very quick, while other inputs send the computer off into a large and complex process which may take seconds or even minutes. As we gain experience in using computers, we learn to expect these delays and correlate them intuitively to the "amount of work" our request might impose on the computer or the network or network resources operating behind the scenes.

Another serious issue to consider is the variation in response time caused by the configuration of the individual workstation or terminal. Clearly, a modern fast processor with adequate memory and a fast modem will respond much more quickly than an older, smaller machine, perhaps with a slower interface to the network. From the perspective of the central service provider, these differences are "somebody else's problem".

Finally, there is the question of identifying which sorts of response time can reasonably be measured. Most computers have internal time-of-day clocks which are accessible from programs, so in theory every response could be timed, if the software on the computer were programmed to do so. In practice, however, most support software does not typically time or record the time from input to response.

These issues lead to different approaches, depending on the goal of the analysis being undertaken. If the question is to address the performance level of a central-service platform, then reasonably uniform requests of that service should be chosen, and timed from the moment the server gets the request to the moment the output is ready to go back to the client. If the performance level of the network is at question, then timings must be developed that reflect the transmission time of messages from node to node on the network, and if the concern is for the configuration of the desktop workstations, then timing software needs to be developed to measure and record that portion of the response time.

This project has begun with the measurement of response times with the object of assessing the performance of central server platforms. Other measures are being considered that also explore the effects of network loading or overloading on composite response times (which include transmission times as well as one or more services). In considersation are modifications to client software which will also permit measurement of overall response times, to include the times involved on the desktop as well as the times consumed by network and server components.

___________

A word about representation:

The graphs displayed here show average response times, in each instance, the average of all the incidents that occurred over a period of 15 minutes is displayed in each bar of the graph.

This means that some of the responses during the 15-minute interval were probably longer, and maybe much longer, than the average value computed. Experience has shown that whenever the average response increases, the variance also increases. Thus, a relatively small variation in these average values usually accompanies a period when response gets more and more erratic. We have learned to take these variations quite seriously: Variations that appear to be relatively innocuous often show periods where response is actually somewhat erratic. The ones that look more alarming frequently correspond to periods when some individual responses are simply unacceptably long.