In the last article in this series, we looked at running automated MQ performance tests using cph tooling inside a docker container and showed how this could be used to test bare metal or containerized MQ performance.
In this article we will look at how JMS performance tests can be automated and run within the Docker environment, but first a small recap on what has changed in the cphtestp performance test image since that previous article.
CSV results are now supported by setting the MQ_CSV_RESULTS environment variable to true to aid exporting of data into your preferred charting tools. You can view the results as before by viewing the docker logs:
$ docker logs containerID
...
# Mon Apr 1 09:55:30 UTC 2019
# Persistence, Msg Size, Threads, Rate (RT/s), Client CPU, IO Read (MB/s), IO Write (MB/s), Net Recv (Gb/s), Net Send (Gb/s), QM CPU
1,2048,1,62.17,0.40,0.00,0.02,0.00,0.00,2.31
1,2048,2,134.65,0.49,0.00,0.02,0.01,0.01,2.24
1,2048,4,200.28,0.60,0.00,0.02,0.01,0.01,2.59
TLS support has been added with the MQ_TLS_CIPHER option. This allows the specification of the CipherSpec to configure on the channel to use when communicating with the QM. The channel name may also provided as an environment variable if the default SYSTEM.DEF.SVRCONN is not used.
You will need to provide a CMS keystore named key.kdb (and its stash file) containing your QM public certificate in the /ssl directory.
On invocation the container will create a CCDT and configure it with the required properties so that the MQI cph client can connect with the desired TLS Cipher to match your QM configuration.
Dockerized JMS testing
Lets now look at the JMS image, how to create it, how it differs from the cphtestp image and the results you might get. The github repository containing the related artefacts and further information is located here:
https://github.com/ibm-messaging/jmstestp
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.1.0.0_amd64.deb
- ibmmq-runtime_9.1.0.0_amd64.deb
- ibmmq-java_9.1.0.0_amd64.deb
The MQ V9.1 client can be obtained from: http://www-01.ibm.com/support/docview.wss?uid=swg24044791
You can build a docker image with the following command:
docker build –tag jmstestp .
and then run in network host mode to connect and run tests against a local QM:
docker run -itd --net="host" jmstestp
The default configuration looks for a QM located on the localhost called PERF0 with a listener configured on port 1420. The clients will send and receive persistent messages. You can override a number of options by setting environment variables on the docker run command. See the aforementioned git repository for more information.
The container will run a number of tests using different numbers of threads with messages of 2K, 20K and 200K. The scenario is a Request/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
which depending on the environment variables set will produce readable output, CSV format results or both:
CPH Test Results
Mon Apr 1 12:37:19 UTC 2019
2K
threads=1
avgRate=157.87
CPU=0.48
Read=0.00
Write=0.02
Recv=0.01
Send=0.01
QM_CPU=3.03
...
# Persistence, Msg Size, Threads, Rate (RT/s), Client CPU, IO Read (MB/s), IO Write (MB/s), Net Recv (Gb/s), Net Send (Gb/s), QM CPU
0,2048,1,157.87,0.48,0.00,0.02,0.01,0.01,3.03
JMS TLS Implementation
One complication is that within the container running the automated JMS test, the scripts use remote runmqsc command to clear the queues that the tests will use. This is straightforward when TLS is not involved as we can configure our remote QM connection details and set them in an MQSERVER envvar before invoking runmqsc –c.
To run JMS tests with TLS configured, we will need the CCDT configured locally and also a CMS keystore available for runmqsc to communicate with the QM securely; thus you will still need to supply a CMS keystore in the /ssl directory alongside the JKS keystore in the /ssljks directory for the tests to run correctly. You can specify the CipherSuite to use with the JMS clients by setting the MQ_JMS_CIPHER envvar. The CipherSpec configured in the CCDT for use by runmqsc will use the MQ_TLS_CIPHER. As the password to the JKS keystore cannot be provided in a stash file, you will also need to provide the password so that the clients can access the keystore correctly; use the MQ_JMS_KEYSTOREPASSWORD envvar.
If you need help determining which Cipher Suites and Cipher Specs are compatible, check the compatibility page:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q113220_.htm
The current version of Java that the docker image inherits from is Java 8 SR 5 FP 27, this contains the full strength cryptography suites. If you are using a back level JDK, you may need to take steps to enable the latest cipher specs (if available in your geography).
JMS Results
Although there are differences in the JMS container setup, the test scenario is exactly the same as the CPH container, and produces similar results (although the JMS clients are more CPU intensive than their MQI equivalents).
The following chart compares the 2K Persistent messaging scenario running on two machines. One hosting the test container (JMS or CPH) and the other runs a containerized MQ (based on https://github.com/ibm-messaging/mq-container).
Hardware: x3550 M5, 2×14 Core, 128GB RAM, Local SSD