WebSphere MQ, formerly known as MQSeries and referred to simply as “MQ” in this article, is a message queuing software from IBM. Introduced in the mid-1990s, MQ has become the de facto standard for asynchronous application communication. MQ usually doesn’t cause excessive performance problems, but it can cause headaches if it’s not tuned.

This is the first part in a two part series on tips for improving MQ performance. The tips are written from a mainframe perspective, but the majority apply to distributed platforms as well. They are not presented in any particular order, although the first rule—MQ is not DB2— is a fundamental one. The tips are also general enough to be true for all versions of MQ; however, they were written for v7.5, the version used in many IT shops.

Tip #1: Always Remember That MQ Is Not DB2

By definition, MQ is a message queuing software. While it’s very tempting to use it literally to queue messages—store them for further processing—MQ is actually for forwarding messages. (You will want to use DB2 for storing data.)

If you do use MQ to store messages, it will almost always result in poor performance. Messages are typically stored in a specific order (FIFO or by priority). To retrieve a specific message using a specific MsgID and/or CorrelId, the queue manager has to browse through all messages in that queue, which takes a significant amount of time. For a queue with just a few thousand messages, the lookup for the right one can go well into seconds, which might as well be eons in the world of application performance. It takes even longer when the application doesn’t use one of the message IDs and tries to get a message based on its contents. It must read every single message using the BROWSE option, so that the messages are not destructively read, and check their contents.

MQ for z/OS has an index facility that helps retrieve messages by their ID more efficiently. Remember, however, that the net gain is significant only if there are just a few updates to the queue. Rebuilding the index of a queue is a CPU-costly operation, so the gain in response time comes at the expense of CPU cycles.

Tip #2: Use MQ Statistics and Accounting (z/OS) Thoughtfully

MQ, as other z/OS software, can have detailed statistics and accounting information written to SMF records, specifically SMF 115 and SMF 116. The information is very helpful in performance tuning and understanding what applications do with MQ, what calls are used, how much CPU they burn, etc. However, this wealth of information comes at the expense of performance. Use statistics and accounting with care. As a rule of thumb, turn them on in testing environments, but use them in production only when needed. If you have to use them all the time, consider gathering only statistics (115) (and remember, not everything needs to be collected) and try to avoid accounting (116).

Version 8 of MQ introduces even more statistics—for channels and channel initiators. While their value for troubleshooting is undisputable, more accounting always comes at a cost.

Tip #3: Be Mindful of Unnecessary Persistent Messages

2 Pages