Recently I was asked how it was possible to confirm that MQ channels configured with COMPMSG(ZLIBFAST) running on IBM z15 were using on-chip compression (Integrated Accelerator for zEnterprise Data Compression or zEDC), which replaces the optional zEDC on PCIe feature on the IBM z14 and earlier platforms.

Whilst the resolution of that was generally unsatisfactory (you can confirm that on-chip compression is occurring on the LPAR but not specifically in use by the MQ channel initiator - at least without the use of a sampling tool), I realised that with the new IBM z16, I had not taken a deeper dive into the performance of channel compression and when it might offer performance benefits in terms of improved throughput or reduced cost.

There is now a "Channel compression on MQ for z/OS" white paper available on the  mqperf github repository, but what follows is a short overview.

MQ supports multiple compression options - RLE (Run Length Encoding) which is good at compressing repeating characters and 2 levels of ZLIB compression. ZLIBHIGH will attempt to compress the data as much as possible but will use extra cycles, and ZLIBFAST which will attempt to get a reasonable level of compression with a view to spending less time compressing.

The advantage of ZLIBFAST on IBM System Z machines is that if the hardware is available and the data to be compressed or inflated is larger than the threshold of the compression engine, the compression will be attempted using the on-chip compression engine. If the data is too small or zEDC is not available, ZLIBFAST will result in the compression and inflation being attempted in software.

In order to have the possibility of saving CPU cycles in the MQ channel initiator whilst using compression, that additional cost needs to be offset by saving cycles elsewhere.
The most likely candidate for saving CPU is when using TLS ciphers to protect the data flowing over the network. In our investigations, the cost of encrypting/decrypting data is largely independent of TLS cipher, although the TLS 1.3 cipher "TLS_CHACHA20_POLY1305_SHA356" is significantly more expensive as it is unable to offload encryption to the CP Assist for Cryptographic Function (CPACF) processors.
In our measurements, we found that the cost of compression was only offset sufficiently by reducing the encryption costs for cipher TLS_CHACHA20_POLY1305_SHA356.
To see benefits in other ciphers, we had to rely on the compression of data reducing the frequency of secret key negotiation (SSLRKEYC). Even in this configuration, benefits were only observed on TLS 1.2 ciphers prefixed ECDHE and not those prefixed TLS_RSA.


It is worth highlighting that highly compressible messages being sent over MQ channels with COMPMSG(ZLIBFAST) may see significant impact to performance when the message is too small to be inflated using the hardware. In the following chart we show how the inflate time as reported by the COMPTIME attribute increases more than 6 times when the message is 95% compressible when compared to a similar sized message that is only 80% compressible. As the decompress was performed in software, we found the cost per message attributed to the channel initiator increased by 60%

Summary

As a general rule, compression is not free, even when MQ for z/OS is able to use on-chip compression as there are software cycles required to set up the environment to request compression.

You should consider why you want to use compression over MQ channels. For example:

• Are you attempting to reduce cost on z/OS?
• Are you attempting to reduce the amount of data flowing over the network?
• Are you attempting to improve throughput rate?
• Is your data compressible?

In order to make a decision on whether compression can help with the first three of those questions, you really do need to be monitoring your MQ subsystems. Enabling and monitoring the TRACE(A) CLASS(4) and TRACE(S) CLASS(4) data or just by using the DISPLAY CHSTATUS command can help.

Ultimately which, or indeed whether any, type of compression is right for you will depend on the data and message size you are sending over the MQ channels.

This is all described in much more detail in the  "Channel compression on MQ for z/OS" document.

To circle back to the original question, i.e. how do I know whether my MQ channels with COMPMSG(ZLIBFAST) are using zEDC hardware, is that unfortunately the decision whether to compress using hardware is at a lower level than MQ. If there is any zEDC activity detected on the LPAR (which can be verified using SMF type 113 records), and the MQ channels are configured with COMPMSG(ZLIBFAST) and the message data is above the system-wide inflate and deflate thresholds, then compression should take place in hardware.