MQ

This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

When tuning your IBM MQ queue manager channels to deliver messages in the most efficient way, it is useful to know how full your batches are, that is, are you achieving full batches.

Channel Batches

When delivering messages to a remote queue manager, a channel attempts to do so in the most efficient manner by sending a number of messages before asking the target system whether it received them all. This is known as batching. The channel is most efficient when it can send a larger number of messages for each of these confirmation flows, and least efficient when it is confirming each message individually.

However, this efficiency may come with some costs, specifically the need to retransmit more than one message should there be a network failure, and the availability of persistent messages since they are only committed on the target system once the batch has been confirmed. For many, stable networks and the use of non-persistent messages for any real-time traffic, mean that achieving full batches is the most efficient way to move messages.

How full are your batches?

So the question is then, how full are you batches? Traditionally you could calculate this using two values returned to you on DISPLAY CHSTATUS, the MSGS and BATCHES values.

AMQ8417: Display Channel Status details.
CHANNEL(MQG1.TO.MQG2)                   CHLTYPE(SDR)
BATCHES(20)                             CONNAME(127.0.0.1(1702))
CURRENT                                 MSGS(500)
RQMNAME(MQG2)                           STATUS(RUNNING)
SUBSTATE(MQGET)                         XMITQ(MQG2)

You would divide one by the other and it would tell you an average of how full your batches were. For example, imagine we sent 500 messages in 20 batches over a channel which has the maximum batch size (BATCHSZ) configured at 50. From those two values you can see that you are getting an average of 25 messages per batch. However the average doesn't tell you the whole story. It could be 20 equal sized batches with 25 in each, or 9 full batches of 50 and some smaller ones. It all rather depends on the arrival rate of your messages on the transmission queue of course!

One more attribute in your tool box which was added in WebSphere MQ V6, is a monitoring value XBATCHSZ. This is an MQ indicator value, which is means it provides a pair of values, a short term indicator and a long term indicator. These values keep a rolling average of your actual batch sizes. To have your channel calculate this you must enable channel monitoring by defining the channel to have MONCHL(HIGH). The short term indicator keeps the rolling average skewed more towards recent activity.

AMQ8417: Display Channel Status details.
CHANNEL(MQG1.TO.MQG2)                   CHLTYPE(SDR)
BATCHES(30)                             CONNAME(127.0.0.1(1702))
CURRENT                                 MSGS(520)
RQMNAME(MQG2)                           STATUS(RUNNING)
SUBSTATE(MQGET)                         XBATCHSZ(1,11)
XMITQ(MQG2)                          

Message Arrival Patterns

Let's now look at a few different patterns of message arrival and delivery.

Pattern A

Here we have an initial trickle of messages and then a large number of messages arriving on the transmission queue, so our short term indicator shows a high value because the most recent batches were full, but our long term indicator shows it wasn't always that way. Note that the indicators will never get all the way to full batches because it is calculating a rolling average and so is always affected by that initial set of small batches.

Pattern B

Here we have an initial large number of messages arriving on the transmission queue ensuring the first 10 batches are full, and then tailing off into a trickle, so our short term indicator shows a low value because the most recent batches were quite small, but the long term indicator show it was previously higher.

Pattern C

For this pattern, we have a steady flow of messages arriving on this transmission queue, such that each batch is not full but it is consistent. Both short and long term indicators show the same value so this is a consistent predictable pattern. Not a lot to see in a graph so I have not added one for this pattern. Given what you see above, if you ever see the XBATCHSZ indicators show the same value, and the calculated average you get from doing the division of BATCHES into MSGS yourself is also the same, you have had exactly the same size batches all through the running of this channel instance. Probably the only realistic way that is ever going to happen is with full batches!

Summary

Knowing how big your achieved batches are is only the start. Next step is to look into tuning them. There is a great resource that covers using BATCHINT, the SupportPac document MD0C: Keeping Channels Up and Running. Check it out!