How_to_Understand_Performance_Problems by gentleman98


More Info
									    How to Understand Performance
Learning to understand the performance of a running system is
unavoidable for the same reason
that learning debugging is. Even if you understand perfectly and
precisely the cost of the code you
write, your code will make calls into other software systems that
you have little control over or
visibility into. However, in practice performance problems are a
little different and a little easier
than debugging in general.
Suppose that you or your customers consider a system or a
subsystem to be too slow. Before you
try to make it faster, you must build a mental model of why it is
slow. To do this you can use a
profiling tool or a good log to figure out where the time or other
resources are really being spent.
There is a famous dictum that 90% of the time will be spent in
10% of the code. I would add to
that the importance of input/output expense (I/O) to performance
issues. Often most of the time is
spent in I/O in one way or another. Finding the expensive I/O and
the expensive 10% of the code
is a good first step to building your mental model.
There are many dimensions to the performance of a computer
system, and many resources consumed.
The first resource to measure is wall--clock time, the total time that
passes for the computation.
Logging wall-clock time is particularly valuable because it can
inform about unpredictable
circumstance that arise in situations where other profiling is
impractical. However, this may not
always represent the whole picture. Sometimes something that
takes a little longer but doesn't burn
up so many processor seconds will be much better in computing
environment you actually have to
deal with. Similarly, memory, network bandwidth, database or
other server accesses may, in the
end, be far more expensive than processor seconds.
Contention for shared resources that are synchronized can cause
deadlock and starvation. Deadlock
is the inability to proceed because of improper synchronization or
resource demands. Starvation
is the failure to schedule a component properly. If it can be at all
anticipated, it is best to have
a way of measuring this contention from the start of your project.
Even if this contention does not
occur, it is very helpful to be able to assert that with confidence.

To top