WebSphere Message Queue Performance Quick Checklist

Notes: This checklist is to provide readers a quick and handy reference of factors influencing the performance of WebSphere Message Queue (WMQ), based on my previous works and other IBM published resources. It is not meant to be a detailed guidance or discussions of the performance tuning. However, it indeed provides the list of parameters that the reader can look into for investigating further any performance issues.

Hardware & software requirements	Don’t forget to check these requirements that can be found at WMQ infocenter.
Separate log and data file systems	Log I/O and queue manger can cause contention on disk usage. To avoid it, use separated and dedicated physical devices for log and queue data.
Data cache	Specify file system cache to the queue data, while no cache to the queue log.
Storage type: SAN, NAS, solid state disk	SAN/fiber channel has less I/O overhead than NAS/NFS. In addition, SAN disk has the writecache feature that can improve I/O performance.
Network connection speed and latency	10 Gigabit network adapter is better than 1 Gigabit for large volume of messages. Also the storage location must be close to the MQ server.
TCP connection	Keep TCP connection alive.
Persistent and non-persistent	Much high throughputs can be achieved with non-persistent messages.
Queue buffer	The maximum values of DefaultQBufferSize and DefaultPQBufferSize are 100 MB per queue. Make sure that enough real memory is available, since each queue would have the real memory of the value defined with DefaultQBufferSize or DefaultPQBufferSize To make the change of DefaultQBufferSize and DefaultPQBufferSize, the queue manager has to be stopped and re-started. In addition, in the case of DefaultQBufferSize , the queue must be deleted and re-created.
Parameters defined in queue manager log	The log is only relevant to the persistent messages. Circular logging has a better performance than leaner logging. However, the trade-off is that learner logging provides more robust data recovery capability. The number of log files should be defined to have sufficient primary logs to hold the active log plus the new log files used until the next checkpoint. When secondary logs are needed, they will be instantly formatted which will cause the delay. As long as there is enough disk space, use the maximum size of LogFilePages, which is 650535. It is better to have a small number of larger log files. In general, 10-20 log files may be adequate. In general, SingleWrite is a better choice in terms of performance than DoubleWrite or TripleWrite For performance, specify the maximum value of LogBufferPages which is 4096. This will help writes of large amounts of log data and enable large messages to be written in a single log I/O. The type of log and the size as well as the buffer of log file page must be determined and specified when creating a queue manager. However, the number of log files can be modified after the queue manager has been created. The queue manager must be restarted to take the change into effect.
Trusted channel	Specify a value of MQIBindType=FASTPATH in the Channels stanza of the qm.ini. As channels are WebSphere MQ product code and as such are stable, there should be no concerns to run channels as trusted applications.
Trusted listener	In the same way that channels can be run as trusted applications a listener can also be run as a trusted application. MQ_CONNECT_TYPE=FASTPATH must be set in the environment in which the queue manager is started in order to enable the trusted listener.
Channel attribute: SHARECNV	Only for WMQ v. 7 or above. SHARECNV channel attribute of 0 specifies no sharing of conversations over a TCP/IP channel instance. However, by using dedicated TCP/IP channel will disable other features provided by WMQ v.7 such as heartbeating, read ahead, administrator stop-quiesce, and client asynchronous consume.
Number of concurrent applications	When processing persistent messages, it is recommended to run many instances of the application concurrently in order to optimize the efficiency of the queue manager log. It is possible to have tens or hundreds of applications running concurrently without any detrimental impact on queue manager log performance. In this situation the overhead of a log write at commit time is shared amongst many applications.
MQ Cluster	Design & setup your MQ cluster to increase the message processing capability. Information on MQ cluster is available easily. Monitoring the cluster performance (such as watching the queue depth of your cluster queues) is an importance step in performance testing. If the queue depth is high, of course you may add another cluster member into the existing cluster. However, another approach (not known to majority) is to add one or more cluster receiver channel(s) associated with the cluster queue(s).
Application processing and units of work	From a performance point of view, it is important that all applications process persistent message within a unit of work (also referred to as syncpoint).