Chapter 9. Queueing Theory for the Oracle Practitioner

Professionals can argue forever about how best to improve system performance unless there's a way to prove who's right. One way to validate performance improvement conjectures is by trial and error. The problem with trial-and-error performance optimization is that, on average, it's hugely expensive. It costs so much money and time to try each scenario that, frequently, the number of scenarios that a company can afford to test is very small. Often, a company runs out of time or money before finding a satisfactory solution.

Trial and error has hope of being efficient only if some kind of intelligence guides the process of choosing which trial to try next . Such choices are usually based upon some combination of experience, intuition, and luck. However, experience, intuition, and luck are what drive those endless debates:

Analyst : We upgraded to faster CPUs at my former client, and everything became 50% faster overnight. We should upgrade CPUs here immediately, and just cut out the performance problem at its knees.

Other analyst : Well, I think that's a waste of time and money. The last seven projects that I've seen upgrade to faster CPUs regretted the investment, because the upgrade didn't produce any real impact. One of my recent clients upgraded to faster CPUs, and parts of the application actually got slower .

So, who's right? It is certainly possible that each of the phenomena described here did in fact happen the way the teller is telling it. But which one of these experiences might best describe your near future? I'll answer in the form of a more blatantly comical hypothetical dialogue amidst two well-meaning but incompetent analysts who are trying to figure out whether a particular glass is large enough to hold a quantity of water that is stored in a pitcher:

Analyst : We poured water from a pitcher into a glass at my former client, and I can assure you that the glass quite comfortably held the entire content of the pitcher. I say we should dump the water into the glass.

Other analyst : Well, I think it's a disaster waiting to happen. The last seven times I've watched people try to empty pitchers into glasses, the glasses weren't big enough to hold all the water. One of my recent clients poured water from a pitcher into a glass, and the results were horrific. Water went everywhere.

The solution to this argument is clear: stop guessing. Measure how much water is in the pitcher. Measure the capacity of the glass. If the quantity in the pitcher exceeds the capacity of the glass, then don't pour. Otherwise, pour away.

As long as you can measure the quantity of water in the pitcher and the capacity of the glass, you don't have to try the experiment to be reasonably certain of how it would turn out. It's an extremely simple example of a mathematical model . The benefit of the model is an ability to predict the future without having to actually try it first. Of course, we could complicate the model by integrating factors such as the likelihood of spills depending upon the shape of the pitcher's mouth, the steadiness of the pourer, and so on. The smartest solution is to choose the simplest model that produces results that meet our accuracy requirements.

Maybe the analogy would have been more accurate if I had used moon rocks instead of water. Like application workload, moon rocks have irregular shapes that are difficult to model, and they are incredibly expensive to obtain for testing.

Top