jPDM is used to assist in investigating performance regression. Methodologies, processes and tools that fall out of the model help to identify limiting constraints.

Each subsystem with its distinct set of attributes and resources plays a specific role in the system. We use specific tools to both expose specific performance metrics and monitor interactions between subsystems.

Looking back at the theory of constraints, we want to investigate the limiting constraint of a production situation, an instance of the jPDM. The tooling helps with investigating. It's important for the investigation to take the overall system into account. The hardware is shared by all operating system processes. The dominance, therefore, may be caused by a single process or the sum of all processes running on that hardware.

First, we investigate the dominating consumer of the CPU and how the CPU is utilized. The CPU consumption pattern will lead us to the subsystem that contains the bottleneck.

In order to investigate the dominating consumer, we make use of a decision tree. It indicates where the CPU time is spent - in kernel space, user space, or idling. The following diagram shows the decision tree:

The round nodes in the graph represent the dominant consumers of the CPU. The colors represent the jPDM subsystems. Following the decision tree leads us to the subsystem that contains the bottleneck. Identifying the subsystem narrows down the performance regression to a specific category. We then use further tooling to analyze the instance of jPDM, the actual situation.

Since performance issues can originate from an infinite number of things, we need to follow a process to narrow down the causes. If we would not follow a process but blindly peek and poke or guess, we would not only waste time and effort but potentially wrongly identify symptoms as actual dominating constraints.

The dominant consumers of the CPU represent where the CPU time is spent. This is an important information to investigate the situation. It's not sufficient to solely look at the overall amount of CPU utilization. This information alone neither gives us much evidence of the existence of a bottleneck or how much headroom there is, nor does it lead to the dominating consumer. A CPU usage of 60% doesn't tell us whether the CPU is the constraining resource, that is whether adding more CPU would improve the overall responsiveness. The CPU time needs to be analyzed in greater detail.

First, we look at the ratio between CPU user and system time. This indicates whether the CPU time is spent in the kernel for longer than expected and thus whether the operating system is the dominating consumer of the CPU.