Windows Task Manager – The Root of all Evil!

Back when Windows was first released, programs (applications) that ran way with the CPU were a common problem. The first step in solving this problem was to launch Windows Task Manager and see which processes were consuming all of the CPU. However, this lead to a dangerous misconception in later years.

The Resource Utilization based Definition of Performance

So a common problem is that something is slow. So you launch Task Manager (shown below) to figure out how utilized your CPU, memory and network are and how busy your disk drives are. This may have been useful at some level and at some time in the past, but it has lead to a dangerous misconception.


The misconception was that high resource utilization meant poor application performance and that low resource utilization meant that all applications were performing acceptably. This may have been at least partially true when there was one application and one operating system running on a physical server, but with hypervisors, JVM’s and soon containers, this mapping of resource utilization to application performance no longer holds.

Unfortunately, Windows Task Manager taught generations of systems administrators to look first at how the resources on the servers were being utilized.

Performance is Equal to Response Time and Throughput

We will blog on this a lot more in the future, but in this world of highly distributed, rapidly changing applications that are abstracted from their infrastructure, we need to redefine performance. We should define performance as how long it is taking to get something done (response time) and how much work is getting done per unit of time (throughput). Nothing else matters.