Some consumption rate curves in MQPerf standard show deep holes. Is this an error ?

The MQPerf probe aims at identifying a performance optimum. The tests most probably use up all of some system resources, so are very likely to be impacted by any external event which would need such resources. For example a test being performed on a workstation, while the programmer executes some heavy tasks, will result in oscillating production and consumption curves, with possible deep holes.

Using a Windows client workstation is a special case. You may notice random freeze periods on such a system, for a 5 seconds duration. Such freezes naturally impact the MQPerf tests. They show on the production and consumption curves as 5s holes, and also impact the system indicators in the MQPerf standard report, notably the number of pending messages.

The holes do have a logical explanation, but we can draw the following conclusions from this experiment:

• JORAM performs its MOM duty despite the freeze periods. They only have a minor impact on the application, reducing the global system performances, and raising the latency for the messages produced during those periods.
• even if you may use the MQPerf tested machine, you had better not do it to avoid registering interfering events.
• Windows client is definitely a bad choice as a production supporting system for JORAM, but this should be obvious. Such freeze periods never occur on a Linux system.