On a business trip, a friend and I make a side visit to Salt Lake City, to work in
some downhill skiing. Three weeks before, I had sprained my ankle but it's start-
ing to recover. The high ski boots, I am thinking, will brace my ankle enough to
avoid pain. We wake up to 8 inches of fresh powder and not a cloud in sight. My
ankle throbs, but I know those ski boots are stiffer than any plaster cast. I am con-
vinced the ankle will be fine. As we try on our boots mine feel like ... well ... like
they might just hold my ankle together if I can endure the gathering pain. I crank
them still tighter.
One look down the slopes shatters my illusions. Ed Elze, my ski partner, is a
member of a volunteer ski patrol at home, while I've recently graduated from
reckless beginner to aggressive intermediate. Most skiers love new snow. I learned
to ski in poor conditions and powder scares me to death. I let Ed, and the reassur-
ing firmness of my boots, convince me that turns in powder will be easier to make
if we're skiing in steeper terrain. Without waiting for objections, he speeds down
an unmarked, isolated canyon. I follow. At least no one will hear me scream.
We need caches!
A surprising number of system cycles are burned doing work that just does not
need to be done. Most Internet sites that deploy database engines make
expensive connections and close them instead of reusing them. Implementa-
tions might rely on several small communications when one would do the
trick. At the core of this chapter are cache-related antipatterns . In general, a
cache is a solution to this basic problem: we are spending most of our process-
ing time fetching data that we've already retrieved recently. We'll refactor our
bulletin board system ( BBS ) servlet by creating a cache to hold that data in
Keep in mind that cache management introduces its own set of problems,
however. Table 5.1 describes some of those issues.
In this chapter, I rely heavily on an article titled “Scaling Up E-business
Applications with Caching,” by Mike Conner, George Copeland, and Greg
art7.htm). The authors created a design for the Command design pattern
defined in chapter 3. Their ideas about the command cache helped me to
organize many of my thoughts in this chapter. Within the article, in three fig-
ures, Dr. Conner illustrates the impact of an aggressive cache strategy on sys-
tem performance. He presents three scenarios; I have condensed the two
extremes and projected the impact of a command cache. Figure 5.1 shows Dr.
Conner's first example. As you can see, nearly all of the requests make it far