even though the machine was running the same single-threaded application with one thread
If there are more threads to run than available CPUs, performance will begin to degrade. In
general, then, you want the processor queue length to be 0 on Windows, and equal to (or less
than) the number of CPUs on Unix systems. That isn't a hard and fast rule; there are system
processes and other things that will come along periodically and briefly raise that value
without any significant performance impact. But if the run queue length is too high for any
significant period of time, it is an indication that the machine is overloaded and you should
look into reducing the amount of work the machine is doing (either by moving jobs to anoth-
er machine or optimizing the code).
1. CPU time is the first thing to examine when looking at performance of an applica-
2. The goal in optimizing code is to drive the CPU usage up (for a shorter period of
time), not down.
3. Understand why CPU usage is low before diving in and attempting to tune an ap-
Monitoring disk usage has two important goals. The first of these regards the application it-
self: if the application is doing a lot of disk I/O, then it is easy for that I/O to become a bot-
Knowing when disk I/O is a bottleneck is tricky, because it depends on the behavior of the
application. If the application is not efficiently buffering the data it writes to disk (an ex-
tion is performing more I/O than the disk can handle, the disk I/O statistics will be quite
high. In either situation, performance can be improved; be on the lookout for both.
The basic I/O monitors on some systems are better than on others. Here is some partial out-
put of iostat on a Linux system: