Improving performance – IBM Websphere Message Broker/ Message Queue

For those building SOA using IBM’s Websphere Message Broker, this article will provide collection of some of the important tips and tricks that will enhance the performance of their solution:

1. Use RouteToLabel node to reduce the cost of processing where multiple paths are desired.

2. Choose your parser carefully. Use compact parsers for discarding white spaces and comments. For example, use XMLNSC for XML parsing but note that MRM XML can provide validation while XMLNSC does not.

3. Parsing only as far as is needed. Use Opaque parser if you do not want to reference the sub tree in message flow processing. However, validation is disabled if you choose Opaque parsing.

4. You can selectively parse headers like MQMD, MQRFH2 or JMS Properties and it might save parsing the whole body where only routing is important.

5. Use XPath carefully. By default an XPath expression will search for all instances of an element in the message. This happens at the expense of a full parse.

6. Use reference variables/pointers in ESQL and Java.

7. Keep the number of tree copy occurance to a minimum. Use minimum number of compute and Java Compute Nodes.

8. Copy data to Environment and refer data from environment, whereever applicable. It reduces the number of times a message tree is copied. If using message body, copy data to be used at the highest level i.e., keep navigation to as high as possible.

9. Use non-persistent messages where reliability is high.

10. Subflows sometimes adds additional processing overhead. Avoid usage of subflows where reusability is not desired.

11. Reduce the number of commits performed by the message flow by choosing Batchsize and Batchint sensibly. Default batchsize is 50.

12. Each additional execution group will need a minimum of 150MB. So ensure enough memory is allocated.

13. Use shared variables to access common data if multiple message flows are running in a single execution group.

14. Review log buffer settings if using persistent messages. Choose circular and linear logging based on your requirement. Linear logging guarantees recovery but at the expense of additional disk space. Automate archiving/ deleting of linear logs. Remember Every MQPUT, MQGET, MQCMIT of a persistent message causes a log record to be created for recovery purposes. Keep the log files on fast disks.

15. Where possible keep the applications and broker as close as possible in order to reduce the overall overhead.

16. MQCONN is expensive. Use carefully. MQOPEN is also expensive as compared to MQPUT/MQGET.

17. Use MQSIRELOAD to bounce (stop and start) execution groups at times.

18. Try to cache queue handles if more than one messages are to be processed. Use MQPUT1 if processing only 1 message.

19. Use Fastpath binding to remove IPC (Inter-Process Communication) component. Fastpath binding means that application is trusted. To define a broker as a trusted application, use the -t flag on the mqsicreatebroker command

20. Try to keep message size below 100 MB when using shared queues.

21. Disable trace. To disable the product trace, use the mqsichangetrace command with a level of none.

22. Use multiple channels to increase performance. For example, there can be a separate channel for large messages or messages that of high priority.

23. Using a separate ReplyToQ for each client will affect performance. Try to use a shared ReplyToQ and segregate message using MsgId or correlationId, if applicable.

24. Use Compute node (ESQL) over JCN.

25. When an exception occurs in MQOutput node with the fail terminal not wired, memory allocated to the message and LocalEnvironment is never reclaimed.

26. When you SET or CREATE a FIELD in the Environment/LocalEnvironment remember to DELETE it, and not only DETACH it, before the end of the flow.