Understanding the Performance Considerations for Persistent Messaging in distributed MQ
Persistent, transacted messaging is a fundamental capability of MQ, delivering the capabilities that are essential to so many modern business applications. There is a trade-off between performance and persistence however.
A paper on persistent messaging performance is now available, with particular focus on, and examples for Linux on x86 platforms. You can download the paper from our MQ Performance page on GitHub: MQ Performance documents (https://ibm-messaging.github.io/mqperf)
MQ is designed from the ground up to optimise transaction logging, but best practises can help you get the most out of your persistent messaging solutions. The paper describes these with illustrations, where applicable, of the benefits that these bring:
- Only use persistent messaging when necessary for your application.
- Size your transaction log correctly.
- Concurrency optimizes the MQ logger throughput.
- Spread message load across multiple queue where possible, to alleviate queue locking.
- Use syncpoint with persistent messages (even if there is only one MQPUT in your transaction).
- Set LogBufferPages=4096 in qm.ini
- Host a queue manager’s error logs on a different location to the transaction log, to avoid being unable to write errors.
- Avoid Long Running Transactions.
- Understand your application and requirements.
- Establish infrastructure capabilities outside of MQ to better understand possible bottlenecks.
Some filesystems are compared to show the relative performance that might be seen in different configurations (e.g. SAN vs NFS over local, dedicated 10Gb link).
There are also illustrations on using tools such as iostat and amqsrua to evaluate your transaction log filesystem performance.