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

MQ for z/OS version 9.2 - Performance report available!

By Anthony Sharkey posted Fri October 09, 2020 04:56 AM

  

Following the recent announcement of IBM MQ version 9.2, I am pleased to say that the IBM MQ for z/OS version 9.2 performance report is also now available.


The report shows that when migrating to 9.2, the performance of existing workloads will remain comparable.

In addition the report details the performance of the new features and I will briefly highlight some of those features below:

  • TLS 1.3 cipher support for MQ channels plus aliasing to allow MQ to negotiate the most secure cipher between partners.
  • zHyperWrite for active logs, which can reduce I/O times by up to 60% for active logs that are synchronously replicated between two storage subsystems.
  • Data set encryption support to provide enhanced data protection for z/OS data sets, giving clients the ability to encrypt all of the data associated with entire applications, without the need to make application changes.

The Advanced VUE offering also includes the additional features:
  • AMS Interception on server to server channels, which allows the enterprise to protect their MQ data using AMS qualities of protection without mandating all of their business partners apply the same level of AMS protection or even AMS protection at all.
  • fasp.io gateway, which provides a fast TCP/IP tunnel that can significantly increase network throughput for IBM MQ particularly on high latency networks, with up to 72 times improvement in throughput for 1MB messages.

Finally, the latest update of MP16 – the capacity planning and tuning guide for MQ for z/OS is available and includes performance information on zHyperWrite for active logs, data set encryption and TLS 1.3 cipher support for MQ channels.

 
These documents, along with many other performance documents can be found on the mqperf github repository.

 



#IBMMQ
#MQ
4 comments
35 views

Permalink

https://community.ibm.com/community/user/blogs/anthony-sharkey1/2020/10/09/mq-for-zos-version-92-performance-report

Comments

Anthony Sharkey
Wed October 21, 2020 09:35 AM

There should be nothing to prevent you specifying a particular TLS 1.3 cipherspec in the SSLCIPH attribute as per your example, rather than using one of the aliases - but you should ensure that both ends support the named cipher. Note that these costs are indicated on page 42 of the report in the section titled "Starting TLS channels".

The benefit of the TLS 1.3 ciphers when using one of the aliases such as ANY_TLS13 is that the partner queue managers will negotiate the strongest common cipher of the TLS 1.3 ciphers.

However, even if you specify a particular TLS 1.3 cipher, the channel start costs do currently include the cost of setting up multiple key shares- and that is what we are investigating..

Hope that helps explain the situation.

Regards, Tony

Tim Zielke
Wed October 21, 2020 09:19 AM

Thanks, Anthony!

From an administrative standpoint, being able to do something like the following would be ideal for TLS 1.3:

DEFINE CHL(ABC) +
SSLCIPH('ECDHE+TLS_AES_256_GCM_SHA384')

Anthony Sharkey
Tue October 20, 2020 01:46 AM

Hi Tim,

Thanks for taking the time to have a read.

You are correct - a large part of the reason for the increased cost in the TLS 1.3 case is that MQ is building key shares for all of the potential key pairs. We are in the process of investigating whether we can reduce the cost of the channel start when explicitly requesting a specific cipher.

Tim Zielke
Mon October 19, 2020 01:17 PM

In the "Starting TLS Channels" section of the IBM MQ z/OS 9.2 Performance Report, it shows the following CPU costs:

TLS_AES_256_GCM_SHA384 (TLS 1.3) = 14.61 ms (millis, I believe)

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (TLS 1.2) = 3.96 ms

These two ciphersuites are for the most part the same when TLS 1.3 uses ECDHE for the pre-master secret share between the client and server.  It sounds like TLS 1.3 is so much higher in CPU start time because it has to build public/private keys for all the potential public/private key groups and not just ECDHE.  Is there a way to tell MQ to only build private/public keys for ECDHE when using TLS_AES_256_GCM_SHA384 so this CPU overhead can be reduced (ideally, get more inline with its TLS 1.2 ciphersuite equivalent)?