The first blog in this series compared the messaging performance of MQ on the bare metal with MQ deployed within a Docker container.

As that article explains there is a performance cost, but the benefits that deploying and running your applications within a Docker environment provide often far outweigh the costs. This article expands on the first blog by looking at how anyone can easily perform some performance tests by running a Docker image that executes performance tests either against an existing bare metal or Docker contained QM(Queue Manager).

Docker image setup
The github repository containing the related artefacts and further information is located here:

Once you have cloned the repository, you will need to separately download the MQ client (for which license agreement is required) and copy the following files into the root directory before building your docker image:

  • /lap/
  • ibmmq-client_9.0.4.0_amd64.deb
  • ibmmq-runtime_9.0.4.0_amd64.deb

The MQ V9 client can be obtained from:

Proceed to perform a docker build as normal:

docker build --tag cphtestp .

The resultant image then contains the MQ client, CPH and scripts to run the containerized tests. CPH is a performance test harness that uses the MQI interface to interact with the MQ QM. Its written in C/C++ and is also available at

The image can then be run in network host mode to connect and run tests against a local QM:

docker run -itd --net="host" cphtestp

The default configuration looks for a QM located on the localhost called PERF0 with a listener configured on port 1420. You can override a number of options by setting environment variables on the docker run command:

Environment variable	Description				    Default if not set
MQ_QMGR_NAME		Queue Manager Name		            PERF0
MQ_QMGR_HOSTNAME	Hostname where QM is running	            localhost
MQ_QMGR_PORT		Port where QM listener is running	    1420
MQ_QMGR_CHANNEL	Channel name to use to connect to QM		    SYSTEM.DEF.SVRCONN
MQ_RESPONDER_THREADS	Number of responder threads to run	    200
MQ_QMGR_QREQUEST_PREFIX	Prefix of request queues to use	            REQUEST
MQ_QMGR_QREPLY_PREFIX	Prefix of reply queues to use		    REPLY
MQ_NON_PERSISTENT       QOS to be used by connecting clients        0 (Persistent)
MQ_USERID		Userid to use when authenticating	
MQ_PASSWORD	        Password to use when authenticating	
MQ_CPH_EXTRA	        Additional string field to propogate to cph client	

So if you wanted to run it against a QM named QMTEST on machine connecting on port 1450, you could use:

docker run -itd --net="host" --env MQ_QMGR_NAME=QMTEST --env --env MQ_QMGR_PORT=1450 cphtestp

Using the image
The container will run a number of tests using different numbers of threads with message sizes of 2K, 20K and 200K. The scenario is a Requester/Responder scenario as featured in the latest xLinux and Appliance performance reports available here:

When the testing is complete the final results will be posted to the docker logs and can be viewed in the normal way:

docker logs <containerID>

You can also obtain the available results by:

docker cp <containerID>:/home/mqperf/cph/results .

The output from the running responder and requester processes can be viewed by:

docker cp <containerID>:/home/mqperf/cph/output .

or you can open an interactive session with the container by:

docker -it <containerID> /bin/bash

We can also use it to test against a QM deployed in another container, and as you can recall from the previous blog, the MQ QM can be launched by:

docker run --env LICENSE=accept --env MQ_QMGR_NAME=PERF0 --volume /var/dvm:/var/mqm --publish 1420:1420 --detach mqperf

or if you want the mq container to use the host network:

docker run --env LICENSE=accept --env MQ_QMGR_NAME=PERF0 --volume /var/dvm:/var/mqm --detach --net="host" mqperf

and then we can launch the test harness to gather the results:

docker run -itd --net="host" cphtestp

and if we wanted to follow up by running some Non Persistent performance tests, we could then execute:

docker run -itd --net="host" --env MQ_NON_PERSISTENT=1 cphtestp

So with two simple commands (and some docker preparation) we can launch an MQ QM and perform load tests from within a containerized environment. This can provide a good indication of the performance of any QM deployed on this same hardware (whether within a Docker container or not) – though ensure that the Docker QM you are using has access to the same IO system that any prospective QM might use.

User defined networks
If you want to run your docker workloads in an encapsulated environment, but you want the performance of running on the host network, there is a third option which is to implement a user defined network instead of using the host or the default bridge network.

docker network create -d bridge --subnet messaging_nw
docker run -itd --env LICENSE=accept --env MQ_QMGR_NAME=PERF0 --volume /var/dvm:/var/mqm --net="messaging_nw" mqperf
docker run -itd --net="messaging_nw" --env MQ_QMGR_HOSTNAME= cphtestp

The graph below shows how the user defined network scenario performs much closer to the host network performance than the default docker bridge performance:

Network Comparison Chart

Join The Discussion

Your email address will not be published.