| Author |
Message
|
| zrux |
 Posted: Fri Dec 06, 2019 5:28 am Post subject: channel bandwidth |
 |
|
Apprentice
Joined: 21 May 2006
Posts: 41
Location: UK
|
is there a difference in network bandwidth usage when an application connects to MQ via a SVRCONN channel e.g
Application -> Remote QM
rather then
Application to local QM--> remote QM ?
we see a drastic decrease in traffic using the 2nd approach and the channel compression is not enabled in either. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Dec 06, 2019 5:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Pedantically, the queue manager on the other end of a SVRCONN channel is it's local queue manager irrespective of the actual location of said queue manager.
This is marginally important as it touches to your second case. In the first instance, connecting to a queue manager not on the same host ("remote" in your diagram) is a straightforward synchronous network connection to a queue manager the application considers local. Awesome.
In the second case the application is not connected to the remote queue manager at all; the queue manager is. So your SVRCONN terminates with the "local" queue manager (getting amazing performance because the TCP/IP stack is all in memory) and traffic to the remote queue manager is carried by the SNDR/RCVR pair that you're using and is subject to the network and the batching & other configuration associated with those channels.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zrux |
| Posted: Fri Dec 06, 2019 6:21 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006
Posts: 41
Location: UK
|
Thanks Vitor..
Last edited by zrux on Fri Dec 06, 2019 12:36 pm; edited 1 time in total |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Dec 06, 2019 10:40 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
There can certainly be a significant difference between the amount of Network bytes sent for a Sdr/Rcvr vs a Svrconn/Clntconn channel pairing. The client connection will use more since it needs to send the entire MQI call (MQPMO, MQGMO, MQOD etc etc) and they essentially have to go in both directions. How noticeable this all is depends a lot on message sizes. The smaller the message the more of a percentage these extra structures will be. If your messages are only 100 bytes long then the bulk of the traffic will be these headers. Of course that is also true for the Sdr/Rcvr case too.
It is certainly possible that the 100GB vs 30 GB is driven only by it being a client but I would be interested in other metrics. It is really the same number of messages (and message data)? How many other calls is the client making ? For example, if it is a badly written application which opens the queue for each message it puts it can have a large impact on overall bytes sent.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 06, 2019 11:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I echo the enlightened comments of my worthy associate, with whom I would never argue about channels.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 06, 2019 4:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
In addition to excessive MQOPENs by the client, it could really be poorly written and be connecting and disconnecting to the queue manager for every message. All that sloppy overhead would be eliminated between queue managers (assuming reasonable channel settings).
The overhead of connecting/disconnecting for every message is even worse if SSL and/or Security Exits are being called to do their thing on every connection attempt.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Dec 06, 2019 7:30 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Indeed there are a great many things the application could be doing - for example using a really short MQGET wait interval or whatever. Activity trace or Accounting and Statistics messages would be a good way of spotting these types of problems.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Dec 07, 2019 2:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Put another way, the code used to move messages between queue managers is guaranteed to be more efficient than the code used by a random MQ Client app. That queue manager to queue manager code was written by MQ experts and has decades of testing by thousands of customers.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zrux |
| Posted: Sun Dec 08, 2019 2:23 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006
Posts: 41
Location: UK
|
|
| Back to top |
|
|
|
|
