ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ Supportchannel bandwidth

Post new topicReply to topic
channel bandwidth View previous topic :: View next topic
Author Message
zrux
PostPosted: Fri Dec 06, 2019 5:28 am Post subject: channel bandwidth Reply with quote

Novice

Joined: 21 May 2006
Posts: 13
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
View user's profile Send private message
Vitor
PostPosted: Fri Dec 06, 2019 5:54 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25901
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
View user's profile Send private message
zrux
PostPosted: Fri Dec 06, 2019 6:21 am Post subject: Reply with quote

Novice

Joined: 21 May 2006
Posts: 13
Location: UK

Thanks Vitor..

Last edited by zrux on Fri Dec 06, 2019 12:36 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Dec 06, 2019 10:40 am Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 952
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
View user's profile Send private message Visit poster's website
Vitor
PostPosted: Fri Dec 06, 2019 11:05 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25901
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
View user's profile Send private message
PeterPotkay
PostPosted: Fri Dec 06, 2019 4:32 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7592

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
View user's profile Send private message
PaulClarke
PostPosted: Fri Dec 06, 2019 7:30 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 952
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
View user's profile Send private message Visit poster's website
PeterPotkay
PostPosted: Sat Dec 07, 2019 2:22 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7592

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
View user's profile Send private message
zrux
PostPosted: Sun Dec 08, 2019 2:23 am Post subject: Reply with quote

Novice

Joined: 21 May 2006
Posts: 13
Location: UK

thanks guys
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ Supportchannel bandwidth
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.