The most wide-spread metric related to computer resources, especially in capacity management and production monitoring, is resource utilization. When you start designing a system, the available hardware resources are usually a variable. It is one of the goals of the design process to specify hardware needed for the system from the business requirements and other inputs like company policies, available expertise, and required interfaces.

When requirements are measured as resource utilization, they are related to a particular hardware configuration. There are meaningful metrics when the hardware configuration is known. But these metrics don’t make sense until the hardware configuration is decided upon: how can we talk about processor utilization if we don’t know how many processors we need? Such requirements are not useful for software if it gets deployed to different hardware configurations, and, especially, for Commercial Off-the-Shelf (COTS) software. Furthermore, they don’t work well with new technologies like cloud computing, virtualization, and service-oriented architectures, where hardware resources are shared and /or changing. We speak about resource utilization during early phases of the system lifecycle, but only as a generic policy. For example, a corporate protocol may be that CPU utilization should be below 70 percent.

When required resources are specified in absolute values, it may be considered a performance metric of the software itself, without binding it to a particular hardware configuration. In the mainframe world, MIPS were often used as a metric for CPU consumption, but there is no such widely used metric in the distributed systems world. Metrics like the number of instructions to execute or the number of I/O operations per transaction were sometimes used in modeling, but they were not very practical. Modeling tool vendors probably used some kind of metrics behind the scene, but they didn’t expose them much.

The importance of resource-related requirements is increasing again with the trends of virtualization, cloud computing, and service-oriented architectures. When we depart from the “server(s) per application” model, it becomes difficult to specify requirements as resource utilization, as each application will add only incrementally to resource utilization. There are attempts to introduce absolute metrics, such as the ‘CPU usage in MHz’ or ‘usage MHz’ metric used in the VMware world. The ‘Megacycles’ metric, sometimes used by Microsoft, is another.  Finally, nearly every cloud provider tries to introduce such metrics – Amazon, for example, uses Compute Units.

In the ideal case (when the system is CPU bound and we can scale the system linearly just by adding processors), we could easily find the hardware configuration needed if we had an absolute metric of resources required.

For example, if software needs X units of hardware power per request and a processor has Y units of hardware power, we can calculate the number of such  processors N needed for processing Z requests as N=Z*X/Y. The reality, of course, is more sophisticated. We have different kinds of hardware resources: processors, memory, I/O, and network. Usually we concentrate on the most critical one, keeping in mind others as restrictions.

Nevertheless, it looks like it would be very beneficial to the industry in general to agree on an absolute metric of resources required, and to my surprise, I haven’t heard any discussion about it. There are hundreds of standards produced by IEEE, The Open Group, and other organizations – value of some may be argued about – but it looks like nobody is discussing this missing cornerstone metrics of performance engineering and capacity planning.  Is it the time to agree on one?