The cost of connecting to a z/OS queue manager

Tony Sharkey
Published on 23/07/2018

Connecting an MQ client to a z/OS queue manager is a relatively expensive procedure, which is why we typically recommend that your client applications remain connected for as long as is practical.

In order of cost (lowest to highest), it is more cost-efficient to use the model 1, 2 and then 3.:

1. CONNECT, OPEN, n*[PUT, GET], CLOSE, DISCONNECT
2. CONNECT, n*[OPEN, PUT, GET, CLOSE], DISCONNECT
3. n*[CONNECT, OPEN, PUT, GET, CLOSE, DISCONNECT]

The cost of the put or get is largely dependent upon the message properties, including size, persistence, type of queue i.e. shared or local message.

The cost of the queue open and close may vary significantly if using a shared queue as a result of seeing first-open or last-close impacts (see blog MQ for z/OS – Performance report MP16 update ).

The cost of the connect can be higher than the combined total of the other APIs.

This blog aims to give some indication of the costs of the MQCONNX into a z/OS queue manager, as well as a guide to the costs of using MQ options in preventing connections.

How much does it cost to MQCONNX to a z/OS queue manager?

In the simplest configuration we compare the cost of connecting a client to a SVRCONN channel whilst varying the SHARECNV attribute.

SHARECNV(0): 510 microseconds per MQCONNX – includes the MQDISC cost.
SHARECNV(1): 590 microseconds.

Regarding these costs, 90% is within the MQ channel initiator address space, with the remaining cost shared between the network layer (TCP/IP) and the MQ queue manager address space.

Does a shared listener make a difference to the cost?

Yes – using a shared listener means that MQ needs to update Db2 to ensure a consistent state.

This update adds significant cost to both the MQ queue manager and the Db2 subsystem as well as some increase to the MQ channel initiator.

The following chart shows a breakdown of the cost by address space as a result of changing which listener was connected into.

Breakdown of the cost of the MQCONNX call using local and shared listeners

Notes on chart:
• The queue manager address space costs increased from 13 to 348 CPU microseconds.
• The channel initiator costs increased from 460 to 527 CPU microseconds.
• The Db2 address space costs increased from 1 to 181 CPU microseconds.

What about using TLS ciphers to protect my channel?

When using cipher spec “TLS_RSA_AES_128_CBC_SHA256” to protect the SVRCONN channel, we saw an increase in the cost of approximately 380 microseconds per connect and disconnect.

This increase in cost was primarily in the MQ channel initiator address space.

We also saw that the rate the client was able to connect and disconnect was limited on the client machine due to the local cost of the cipher processing – the majority of the cipher processing was performed on the client machine.

Can I reduce the cost of my connections?

The cost of the MQCONNX and MQDISC can be reduced by suppressing the CSQX511I and CSQX512I messages using the command “SET SYSTEM EXCLMSG(X511,X512)”.

This can make a notable difference to the cost of the connect and disconnect as well as reducing the amount of data logged to the MQ channel initiator job log.

Summary cost of connecting a client to a z/OS queue manager

Costs shown are CPU microsecond per MQCONNX and MQDISC.

Using the table to calculate the cost of the connection:

• Using a local listener on a SVRCONN with SHARECNV(0) cost 510 microsecond.
  • Enabling TLS ciphers added 380 microseconds, for a total of 890.
  • Suppressing the X511 and X512 messages reduced the cost by 130 microseconds.

How much does it cost to prevent a connection to a z/OS queue manager?

MQ offers a number of ways to prevent or limit connections from particular clients. These include channel authentication (CHLAUTH) rules, as well as channel attributes MAXINST and MAXINSTC.

MAXINST specifies the maximum number of simultaneous instances of a server-connection channel that can be started.

MAXINSTC specifies the maximum number of simultaneous instances of a server-connection channel that can be started from a single client.

Preventing access using channel authentication rules

There is a useful tech note of the use of CHLAUTH rules which can be found IBM CHLAUTH made simple.

For our simple testing we blocked all access from the client machine. In all of these cases, no TLS cipher was set, so the costs can be compared against the basic connections.

We measured the cost of preventing access as:
• SHARECNV(0): 800 microseconds per connection attempt.
• SHARECNV(1): 1500 microseconds.

This represents a 300-400 microsecond increase on the cost of a successful connection.

Some cost saving could be achieved by suppressing CSQX777E “Channel SYSTEM.DEF.SVRCONN has been blocked” but suppressing the message does mean more difficulty in determining which machines are attempting to connect.

Preventing access using MAXINST or MAXINSTC

These can be enabled using MQSC commands for example:
• ALT CHL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MAXINST(100)
• ALT CHL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MAXINSTC(5)

Using MAXINST or MAXINSTC to limit the number of simultaneous instances of the server-connection channel resulted in the cost of the blocked connection being:
• SHARECNV(0): 440 microseconds per connection attempt.
• SHARECNV(1): 850 microseconds.

Channels blocked using MAXINST will cause the following messages to be logged:
• CSQX599E “Channel SYSTEM.DEF.SVRCONN ended abnormally connection”
• CSQX489E Maximum instance limit n, exceeded..”

The X599 and X489 messages could be suppressed but again doing so makes determination of problem clients more difficult.

What about rogue connections?

Channel authentication rules can be used to block specific TCP/IP addresses as well as preventing the same client from repeatedly attempting to connect with the use of a delay in responding to the MQCONNX call.

However, if a client machine with an allowed IP address attempts to connect to the MQ channel initiator using an invalid client protocol, the channel initiator may log the following 3 messages:
• CSQX504E Local protocol error
• CSQX053E Error information recorded in CSQSNAP
• CSQX207E Invalid data received
In addition, as message CSQX053E states, data about the invalid flow will be written to the CSQSNAP DD card.

This type of failed connection costs of the order of 1100 microseconds per failure.

The test environment

We recorded these numbers on our performance sysplex running on a 3 CPU dedicated LPAR of a z14 running z/OS v2r3 and the latest levels of MQ code.

A client application was used that issued an MQCONNX and MQDISC, 100000 times, whilst we monitored the costs on the LPAR.

The sysplex was configured with 2 CryptoExpress6S coprocessors and 1 CryptoExpress6S accelerator to assist in the TLS cipher connection measurement.