Shopping For Performance
Article 02/97
A Fable:
Two husbands (Tom and Al) left home at the same time to go to the store. Their tasks were identical: Bring back a loaf of bread and a quart of milk. They drove equal distances to the store, at the same speed.
Tom got to the store, picked up both items. Walked to the checkout line, waited for the person in front of him, paid, and then left.
Al got to the store, picked up the bread. Walked to the checkout line, waited for the person in front of him, and then paid. He then walked back into the store, picked up the milk, walked to the checkout line, waited for the person in front of him, paid, and then left.
The Moral:
Both men did the same amount of "work". Their "transaction," if you will, was to come back with bread and milk. However, their "response time" was quite a bit different. Al took more elapsed time to do the same job. Why? Bad design.
So it is with some applications. If a transaction's processing path is designed to make more passes through a resource or service than it needs to make, the response of the application will be slower.
The classic design mistake in this client-server world is for a client to make multiple calls to the server to get work done. In a well-designed application, the client makes as few calls to the server as are necessary to process the transaction. The application designer has the client make one or two complex calls to the server, as opposed to many smaller calls.
There are obviously many options to consider when designing an application. Some designers prefer to make the calls to the server simple, so that the server handles a set of very simple requests rather quickly. I recommend the opposite. I prefer a complex server, handling a complex transaction. Using the supermarket analogy, an "express-lane" server class could handle the simple, fast transactions, while a different server class would handle the more complex transactions.
In the fable above, Al got off lightly. Both men had to deal with only one queue at the store, and the queue at the checkout line was only one person deep. What would have Al's response time been if there were five people in front of him the second time he went through the checkout line?
In computing, queuing is everywhere. A typical transaction will encounter queuing at the client's CPU; at the communications transport connection to the server; at the CPU in the server computer; at the server process itself; at each disk used; etc. As a designer, you rarely have control over the length of the queue at each point in the path.
The best you can do is design the application to go down each path the fewest number of times.
| 
