MQ REST API performance on z/OS

Tony Sharkey

Published on 14/07/2017 / Updated on 10/08/2017

This blog takes a look at the performance of the MQ REST API specifically on the z/OS platform, which was introduced in MQ 9.0.1 and enhanced in both 9.0.2 and 9.0.3 Continuous Delivery Releases.

Our performance measurements were run using a z13 LPAR running z/OS v2r2 configured with dedicated processors.

The REST API calls were issued from a Linux machine using Python scripts making cURL calls.

How much does authentication cost?

There are a variety of options for the authentication of requests.

In this blog, authentication was achieved using either HTTP Basic Authentication (username and password) or with the use of a LTPA (Lightweight Third Party Authentication) security token that was returned as a cookie and then used on subsequent REST requests.

Additionally RBAC (role based access control) profiles are used to apply access restrictions to different authenticated users using three roles; MQWebAdmin, MQWebAdminRO and MQWebUser.

Using the LTPA token for long-term persistent connections such that multiple REST API calls only needed authentication a single time, reduced the cost of the REST API call by 14 CPU milliseconds.

Costs of the APIs

As of MQ version 9.0.3, the following REST resources are available:

• Installation, equivalent of distributed function “dspmqver”.
• Queue Manager, equivalent of “dspmq” function
• Subset of the data returned from the “DISPLAY QMSTATUS” MQSC command (introduced in 9.0.3)
• Queue (introduced in 9.0.2)

The costs of the REST APIs can vary but typical values observed on our systems were:

Data volumes matter

Give consideration when inquiring queue data with regards to both the number of queues and the attributes required for those queues.

The following 2 charts demonstrate the impact of returning limited data for an increasing number of queues against requesting all queue data.

As can be seen by the 2 charts, filtering the data can reduce the Liberty Server costs significantly – in this example the costs reduced by more than 50%.

Since the filtering occurs in the Liberty Server, the costs to the MQ queue manager remains similar regardless of whether the attributes are filtered.

Reducing the amount of data returned can also significantly impact the round-trip times.

In our measurements where the network impact (bandwidth and latency) was low, the impact from reducing the amount of data can be seen in the following table:

Times shown are milliseconds per request.

Systems where network latency is variable or higher may be impacted by more data being returned.

Updating queues and basic authentication

When using an LTPA security token, the cost of updating an attribute on a specific queue was similar to the cost of issuing the queue GET request, i.e. 8-9 CPU milliseconds.

When using basic authentication, the cost of updating an attribute on a specific queue was approximately double that of the queue GET request. This additional cost was due to having to issue a login GET request to generate the CSRF token cookie, which is then passed in the update using the header ibm-mq-rest-csrf-token.

How does the REST API performance compare with the MQ Console?

In a previous blog titled “Taking a performance view to running the MQ Console on z/OS”, I discussed the costs of the MQ Console as more MQ objects were defined.

The MQ Console “queue widget” returns the queue name, queue type and current depth.

As a comparison, data returned by the REST API Queue GET request is shown for both filtered and unfiltered data.

Costs reported in the table are CPU milliseconds.

The table demonstrates that the costs as a result of the filtered REST API call, costs are similar to the MQ Console with similar function.

Does the number of users impact the REST API cost?

As the number of concurrent users of the REST APIs increases, there is some additional cost in the Liberty Server.

The following chart offers some indication of the increased cost for up to 50 users:

Notes on chart:

1. The use of the REST API queue GET function returns 500 queues.
2. Where multiple REST APIs are mentioned, e.g. “installation and qmgr”, these are the total cost of the 2 calls.
3. These measurements use an LTPA token to log in once and generate a cookie, which is then used on subsequent REST API calls.
4. The costs are based on the average cost of 1000 transactions where a transaction consists of the REST APIs named in the table key.

z/OS Specialty Processor Offload

As a Java™ product, the Liberty server is largely eligible for offload to specialty processors. From the RMF™ Workload Activity reports, we saw between 85-95% of the Liberty costs were eligible for offload.

The costs of satisfying the inquiries from the Liberty server in the MQ queue manager are not eligible for zIIP offload.

Asynchronous TCP/IP sockets I/O for Liberty on z/OS

The Asynchronous TCP/IP sockets I/O for Liberty (AsyncIO) on z/OS® service was introduced in Liberty Server version 16.0.0.3, and instructions to enable the service can be found here.

Our measurements with up to 100 simulated users did not benefit from the enabling of the AsyncIO service.

Since the service is applied at the operating system level, if you find some detrimental impact from the enabling of the service, it can be disabled at the individual server by adding the following property to the bootstrap.properties file:

com.ibm.ws.tcpchannel.useZosAio=false

General Observations

As has been mentioned, the cost of the REST API queue GET function is similar to the MQ Console as the number of queues increases. With increasing numbers of queues, or indeed increasing number of users, consideration should be given to the size and placement of the “SYSTEM.REST.REPLY.QUEUE” with regards to the buffer pool and page set.

Significant proportions of the Liberty server costs can be offloaded to zIIP specialty processor where available, reducing run-time costs.

Conclusion

The MQ support of the administrative REST API using the Liberty server is able to provide good response times for tens of concurrent users and at reasonable CPU costs, when used to administer queue managers with thousands of objects.

It is also able to co-exist in the same Liberty server as the MQ Console without significant impact.