Search This Blog

Wednesday, January 13, 2016

Using Channel compression in WebSphere MQ

Preface

Starting with WebSphere MQ v6.1 IBM introduced the channel compression for the data that flows between queue managers. This is a good feature that makes optimum use of the network bandwidth by using high end systems to compress the data. In this post I will try to take a stab at using message compression.

Create the queue managers and objects

Create two queue managers with the following details - 
Queue Manager Name Listener Port
WQM1 2221
WQM2 2222

Create transmission queues on both the queue managers as follows - 



Queue Manager Name
Transmission Queue
WQM1
WQM2
WQM2
WQM1

Next up, create the sender and the receiver channel that will communicate with each other

Queue Manager Name Sender Channel Receiver Channel
WQM1 WQM1.TO.WQM2 WQM2.TO.WQM1
WQM2 WQM2.TO.WQM1WQM1.TO.WQM2

Create the local queue definition in WQM2 as 'LOCAL.Q' and create a remote queue definition as 'REMOTE.Q.OF.LOCAL.Q' in WQM1. 


If all the objects are created and the channels and listener are running then the message written to REMOTE.Q.OF.LOCAL.Q should end up in LOCAL.Q .

NetTool

For this exercise to keep a tab on the size of the data and the time it takes to send the packets from one queue manager to another, I decided to use NetTool. To know more about NetTool and download, follow this link. Download the zip file and unzip it as a folder in the system.

Protocol Tunneling

Start NetTool by click on the following 'start-nettool.bat' on windows and 'start-nettool.sh' on unix systems and switch to the second tab. This tab allows us to protocol tunnel by having NetTool listen on the port 2222-the listener port for WQM2- and directing the traffic coming on port 2220 to 2222 and click on the 'Listen' button. This will start the tunnel.


With the protocol tunneling in place change the sender channel on WQM1 to use port 2220 instead of 2222. This way we know the time and the data being sent from WQM1 to WQM2.

Without compression

Using RFHUtil, send the message to REMOTE.Q.OF.LOCAL.Q and here is what we see - 



In this scenario a file of 100298 bytes is used to send to the remote queue from WQM1 to WQM2. After the message has been changed, change the compression, right click the channel name and select properties. Change the compression to RLE and save it. Do this to the receive channel as well and restart both the channels. For the sake of parity all the 4 channels have been changed to RLE and need to be restarted.

I changed it across the 2 different message compression and here are the results - 


Starting from top down the order has been ZLIBHIGH, ZLIBFAST, RLE and no compression. The statistics show the progressive message bytes being lowered as the message compression is changed.  







No comments: