Workshop

other. Wow!
Application efficiency typically doesn’t change unless the design of the application causes certain events
to make the app handle things differently at certain thresholds (more than x indexes? More than x users?),
which can affect efficiency. Unfortunately, there’s no formula on how to deal with this; you’ll have to
rely on instinct and then test your theory.
Server Limitations
Every server can run out of resources. Once you identify which server a slow application is running on,
you’ll want to check the following items:
• CPU utilization
• CPU “waiting for I/O” statistic
• Swapping statistics/RAM available
Sure, every CPU can “run out of gas.” But most of the time, you’ll see less than 100 percent CPU
utilization. Even when a lot of CPU cycles are available, you still can be slow. Why? It all boils down to
this: Hard drives are slow as dirt, physical memory is the speed of light. Hard drives don’t even begin to
approach how fast memory is. Consider these analogies:
• Using cache memory is like reaching up to your cabinet to get a can of beans.
• Using regular memory is like walking to your pantry to get a can of beans.
• Using “swap” (or virtual memory) is like getting in your car and driving to the grocery store for
a can of beans.
Is it that bad? Pretty close. Even when the CPU is not busy, if your program has to be “paged” back in to
physical memory from virtual (hard drive) memory, it takes a long time, and your performance is going
to suffer. How much swapping is acceptable? For an answer to that, see the “Baselining” section later in
this chapter.
Finally, your application may be disk intensive, regardless of whether there’s enough physical memory to
go around. Database programs, no matter how well indexed, will suffer performance problems if they’re
on nonoptimized disks. This typically isn’t a “new” problem—you’ll see this from the first installation of
an application. However, if index or database files grow to a certain point, taking up more disk space
(and thus taking longer to load), performance may start to degrade. You can see whether your
applications are “disk bound” by checking your “waiting for I/O” CPU statistic. If it’s a large percentage
of the total CPU utilization, you probably have problems.
Measure Twice, Cut Once
The only way to know for sure whether you’re running out of anything—bandwidth, server resources,