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:
https://github.com/ibm-messaging/cphtestp
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/
- mqlicense.sh
- ibmmq-client_9.0.4.0_amd64.deb
- ibmmq-runtime_9.0.4.0_amd64.deb
The MQ V9 client can be obtained from: http://www-01.ibm.com/support/docview.wss?uid=swg24042176
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 https://github.com/ibm-messaging/mq-cph
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 test.example.com connecting on port 1450, you could use:
docker run -itd --net="host" --env MQ_QMGR_NAME=QMTEST --env MQ_QMGR_HOSTNAME=test.example.com --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: https://ibm-messaging.github.io/mqperf/
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 172.25.0.0/16 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=172.25.0.2 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:
