MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Performance Report Released for MQ V9.4 on x86 Linux

By Paul Harris posted Mon September 09, 2024 04:47 AM

  

Performance Report Released for MQ V9.4 on x86 Linux 

A performance report for the MQ V9.4 long term service release on x86 Linux is now available from the mqperf site on GitHub here:
https://ibm-messaging.github.io/mqperf/MQ_V9.4_Performance_Report_xLinux_v1.0.pdf

This report includes performance tests with the new LZ4 compression algorithms, now supported for MQ channels (see The lowdown on IBM MQ compression - IBM MQ 9.4 LTS and LZ4 ) .

Compression can be useful to optimise performance in low bandwidth networks. The table below shows the benefit of using one of the new LZ4 algorithms (LZ4FAST) over the previous algorithm (ZLIBFAST) or no compression. The benefit will be dependent on a number of factors including the size of the message and how compressible it is (the messages used for the test below were JSON). More details can be found in the report. 

For a list of the current MQ performance reports see our main page on GitHub here: https://ibm-messaging.github.io/mqperf/ 

2 comments
27 views

Permalink

Comments

Wed September 11, 2024 03:20 AM

Thanks for your feedback Andy. I take your point and I think that the benefits of having larger queue buffers is something that might be evaluated in more depth at some point to give some guidance on where these provide benefit. The story is more nuanced, as you say.

Tue September 10, 2024 06:56 AM

Paul,

You state "Note that large queue buffers may not be needed in your configuration. Writes to the queue files are asynchronous, taking advantage of OS buffering. Large buffers were set in the runs here, as a precaution only".

This seems like a very broad statement, I might have been expecting a bit more qualification. Although the writes to the queue files are unforced, the queue manager will periodically force any buffers that contain persistent messages that are not near immediately consumed.  The OS has no idea which buffers relate to which messages and so by and large cannot optimize this process nearly as well as the queue managers own buffer management is able to do so. Buffer management was something I used to chip away at before I retired but lacked significant investment. I'm unaware if greater investment has been made in this area in recent years but I suspect not ?

One of the big conceptual differences between NativeHA and RDQM used to be that NativeHA only ships log writes whereas RDQM ships both log writes and queue files writes (I'm guessing that this is still true). Again I might expect this to have a knock on effect where giving MQ's own buffer  manager more resources (bigger buffers) would have a more significant effect in an RDQM environment.

Best wishes

Andy.