| Author |
Message
|
| sameerg |
 Posted: Thu Feb 02, 2006 2:03 pm Post subject: Websphere MQ Client Message Overhead |
 |
|
Newbie
Joined: 02 Feb 2006
Posts: 5
|
We have an application developed using VB 6.0 front end and Websphere MQ Client communicating with Websphere MQ Server. Over the LAN this architecture works just fine.
We have majority of the users using this application over a wireless radio network with 9.6 K shared bandwidth. Our network experts found out that MQ Series is a very chatty application. It adds a lot of overhead to the application messages. Due to which, we get lot of dropped connections and delays in communication.
Is there a way to avoid / reduce the MQ overhead?
Any setting / property on either client or server?
Any other products / programs / alternate solutions?
Any suggestions?
All your help would be truly appreciated. |
|
| Back to top |
|
 |
| BenR |
| Posted: Thu Feb 02, 2006 11:58 pm Post subject: |
|
|
Acolyte
Joined: 31 Jan 2006
Posts: 60
Location: Hursley, UK
|
| Have you looked at WebSphere MQ Everyplace? WMQ is fairly network intensive, and assumes the network is reliable. WMQe was designed to work over unreliable networks, with a much smaller message size. Sending messages between WMQ and WMQe is fairly straighforward. |
|
| Back to top |
|
|
| sameerg |
| Posted: Fri Feb 03, 2006 8:15 am Post subject: |
|
|
Newbie
Joined: 02 Feb 2006
Posts: 5
|
| BenR wrote: |
| Have you looked at WebSphere MQ Everyplace? WMQ is fairly network intensive, and assumes the network is reliable. WMQe was designed to work over unreliable networks, with a much smaller message size. Sending messages between WMQ and WMQe is fairly straighforward. |
Thanks very much for the reply. I work for the state govt. WMQ Client is free and MQE has a license fee. Before considering MQE we are required to see if we can fine tune the existing product. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 03, 2006 10:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Whenever you issue an MQ call for a client, you send MQ specific data to and from the Queue Manager. So design your code logic to minimize connects, opens, closes, and disconnects. When you have to put, you have to put, nothing you can do there.
If you are doing a GET with wait, know that the client will be sharing a HB with the QM every HeartBeatInterval, a parameter on the client channel. Either up that value real high, or don't leave yourself in a GET with wait.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sameerg |
| Posted: Fri Feb 03, 2006 10:58 am Post subject: |
|
|
Newbie
Joined: 02 Feb 2006
Posts: 5
|
| PeterPotkay wrote: |
Whenever you issue an MQ call for a client, you send MQ specific data to and from the Queue Manager. So design your code logic to minimize connects, opens, closes, and disconnects. When you have to put, you have to put, nothing you can do there.
If you are doing a GET with wait, know that the client will be sharing a HB with the QM every HeartBeatInterval, a parameter on the client channel. Either up that value real high, or don't leave yourself in a GET with wait. |
Currently the HeartBeatInterval on channel is set to 60 Sec. The reason we can not bump it up any further (unless there is some thing else we could do..) is when we loose connection over wireless network, for some reason MQC takes approx. twice the time of HBI which in our case is 60 x 2, to error out and throw MQ Connection error to the VB Client. In short it takes 2 minutes for vb client to know the connection was lost and need to establish a new connection. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Feb 03, 2006 12:30 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
You could look into using compression exits at the send/receive exit points on the channel (and V6 of MQ has built-in compression available). Of course, it doesn't diminsh the number of sends across the link, but could cut down on the bandwidt requirement .....
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 03, 2006 12:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Do you do MQGETs with Wait?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sameerg |
| Posted: Fri Feb 03, 2006 1:11 pm Post subject: |
|
|
Newbie
Joined: 02 Feb 2006
Posts: 5
|
| wschutz wrote: |
| You could look into using compression exits at the send/receive exit points on the channel (and V6 of MQ has built-in compression available). Of course, it doesn't diminsh the number of sends across the link, but could cut down on the bandwidt requirement ..... |
Thanks very much. I was not aware V6 had compression built in, it is worth a try. MQ headers are binary I wonder how well would it compress.
We use compression on our application messages & we get 70-90 % compression, but it's all XML.
BMC has a product called PATROL for WebSphere MQ. Has anyone used this product or knows if it would help in any way to reduce MQ Overhead? |
|
| Back to top |
|
|
| sameerg |
| Posted: Fri Feb 03, 2006 1:19 pm Post subject: |
|
|
Newbie
Joined: 02 Feb 2006
Posts: 5
|
| PeterPotkay wrote: |
| Do you do MQGETs with Wait? |
Yes that is correct, we use MQGMO_WAIT with WaitInterval, which is 5 seconds if the app runs in wireless mode Vs 1 sec if it's LAN.
I think you guys are leading me in the right direction. I do appreciate all your help. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 03, 2006 3:20 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
5 seconds eh? What do you do when that 5 second get with wait returns a 2033? Just issue another 5 second get with wait? If yes, that's your problem, and the cause of your overhead, assuming you are not getting more than 1 message every 5 seconds.
Just issue a long Get with wait, make sure you specify fail if quiescing on the get, and code a little routine after each succesful get to check for a "quit" message so you can graceful ask your app to drop out of the get. With this design, you will only see HBs flowing every HB Interval during the blocking get with wait, and those are only 12 bytes. Otherwise any activity will be application message driven, and there ain't no way around dat.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
