If you have upgraded or are about to upgrade to WebSphere MQ 7.5 – And you have a very high throughput where a large number of messages may reside on a Queue then you may well hit some performance issues.

A performance test in an MQ Cluster environment was severely degraded as messages built up on the SYSTEM.CLUSTER.TRANSMIT.QUEUE. The Build up of messages was not the problem.

If you have upgraded or are about to upgrade to WebSphere MQ 7.5 – And you have a very high throughput where a large number of messages may reside on a Queue then you may well hit some performance issues.

A performance test in an MQ Cluster environment was severely degraded as messages built up on the SYSTEM.CLUSTER.TRANSMIT.QUEUE. The Build up of messages was not the problem. Any monitor which has an agent displaying the current depth may well start to cause a slowdown. The problem is not specific to the SYSTEM.CLUSTER.TRANSMIT.QUEUE – Any Queue that has a large number of messages on it may be subject to the performance issue. The issue is not specific to any monitor, issuing a DIS QL(*) CURDEPTH may have an adverse effect.

IBM do have a fix for this now.

The recommendation is to run performance tests in a Performance Testing environment with all monitoring on with WebSphere MQ 7.5 before you go to live production – That is, if the crieria above is likely to be the case.

. The problem is not specific to the SYSTEM.CLUSTER.TRANSMIT.QUEUE – Any Queue that has a large number of messages on it may be subject to the performance issue. The issue is not specific to any monitor, issuing a DIS QL(*) CURDEPTH may have an adverse effect.

IBM do have a fix for this now.

The recomendation is to run performance tests in a Performance Testing environment with all monitoring on with WebSphere MQ 7.5 before you go to live production – That is, if the crieria above is likely to be the case.