work that we were thinking clearly.
Our work for Mr. Harkey is illustrated
in Table 1.
This was Mr. Harkey’s axiomatic
approach to algebra, geometry, trigonometry, and calculus: one small, logical, provable, and auditable step at a
time. It’s the first time I ever really got
Naturally, I didn’t realize it at the
time, but of course proving was a skill
that would be vital for my success
in the world after school. In life I’ve
found that, of course, knowing things
matters, but proving those things to
other people matters more. Without
good proving skills, it’s difficult to be
a good consultant, a good leader, or
even a good employee.
My goal since the mid-1990s has
been to create a similarly rigorous ap-
proach to Oracle performance optimi-
zation. Lately, I have been expanding
the scope of that goal beyond Oracle
to: “Create an axiomatic approach to
computer software performance op-
timization.” I’ve found that not many
people like it when I talk like that, so
let’s say it like this: “My goal is to help
you think clearly about how to opti-
mize the performance of your com-
user, performance usually means the
time it takes for the system to execute
some task. Response time is the ex-
ecution duration of a task, measured
in time per task, such as “seconds
per click.” For example, my Google
search for the word performance had
a response time of 0.24 seconds. The
Google Web page rendered that mea-
surement right in my browser. That is
evidence to me that Google values my
perception of Google performance.
What is Performance?
Googling the word performance
results in more than a half-billion hits
on concepts ranging from bicycle racing to the dreaded employee review
process that many companies these
days are learning to avoid. Most of the
top hits relate to the subject of this
article: the time it takes for computer
soft ware to perform whatever task you
ask it to do.
And that’s a great place to begin:
the task, a business-oriented unit of
work. Tasks can nest: “print invoices”
is a task; “print one invoice”—a sub-task—is also a task. For a computer
Response time versus throughput
Throughput and response time have
a generally reciprocal type of relationship, but not exactly. The real relationship is subtly complex.
Example 1. Imagine that you have
measured your throughput at 1,000
tasks per second for some benchmark.
What, then, is your users’ average response time? It’s tempting to say that
the average response time is 1/1,000 =
.001 seconds per task, but it’s not necessarily so.
Imagine that the system processing
this throughput had 1,000 parallel, independent, homogeneous service chan-
table 1. the axiomatic approach as taught by mr. harkey.
3.1x + 4 = 13
3.1x+ 4–4 = 13–4
3.1x = 9
3.1x ∕ 3. 1 = 9 ∕ 3. 1
x ≈ 2.903
subtraction property of equality
additive inverse property, simplification
division property of equality
multiplicative inverse property, simplification
nels (that is, it’s a system with 1,000
independent, equally competent service
providers, each awaiting your request
for service). In this case, it is possible
that each request consumed exactly 1
Now, you can know that average response time was somewhere between
0 and 1 second per task. You cannot
derive response time exclusively from
a throughput measurement, however;
you have to measure it separately (I
carefully include the word exclusively in
this statement, because there are mathematical models that can compute response time for a given throughput, but
the models require more input than just
The subtlety works in the other direction, too. You can certainly flip this
example around and prove it. A scarier
example, however, will be more fun.
Example 2. Your client requires a
new task that you’re programming
to deliver a throughput of 100 tasks
per second on a single-CPU computer.
Imagine that the new task you’ve written executes in just .001 seconds on the
client’s system. Will your program yield
the throughput the client requires?
It’s tempting to say that if you can
run the task once in just one thousandth
of a second, then surely you’ll be able to
run that task at least 100 times in the
span of a full second. And you’re right,
if the task requests are nicely serialized,
for example, so that your program can
process all 100 of the client’s required
task executions inside a loop, one after
But what if the 100 tasks per second
come at your system at random, from
100 different users logged into your client’s single-CPU computer? Then the
gruesome realities of CPU schedulers
and serialized resources (such as Oracle latches and locks and writable access to buffers in memory) may restrict
your throughput to quantities much less
than the required 100 tasks per second.
It might work; it might not. You cannot
derive throughput exclusively from a response time measurement. You have to
measure it separately.
Response time and throughput are
not necessarily reciprocals. To know
them both, you need to measure them
both. Which is more important? For
a given situation, you might answer
legitimately in either direction. In