| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Connectivity |
« View previous topic :: View next topic » |
| Author |
Message
|
| RocknRambo |
 Posted: Mon Dec 07, 2009 3:16 am Post subject: MQ Connectivity |
 |
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
We have a requirement to establish MQ connectivity between the two data centers on a dedicated & secured pipleline, and came up with few options:
Peak, message volume is 125K/Sec
1. Queue Manager to Queue Manger
a. Having one transmission queue will be bottleneck in case of the connection failure.
b. Multiple transmission queues, manual load balancing with high volume transactions, perception of the admin team is sender/receiver channels are unreliable, often shutsdown. is this a true statement ?
2. MQ Cluster repository
a. Single transmission queue, could be a bottleneck
3. Client to Queue Manager
a. Is the client connection to the queue manager - a better option Vs QM to QM ?
Can anyone share their experience in providing pros/cons on the above three approaches.
Thanks in advance,
-RR |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Dec 07, 2009 3:56 am Post subject: Re: MQ Connectivity |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| RocknRambo wrote: |
| ...perception of the admin team is sender/receiver channels are unreliable, often shut down. is this a true statement ? |
Not in my experience, especially if the system is 'tuned' to remove or at least reduce the conditions that could potentially cause a channel stop (which should be a given anyway); but SDR/RCVR pairs are always at the mercy of poor network however. As regards single transmission queues being a bottleneck, using class-of-service channels means multiple transmission queues, multiple channels, and therefore provides a degree of confidence that a single bottleneck is removed.
| RocknRambo wrote: |
2. MQ Cluster repository
a. Single transmission queue, could be a bottleneck |
If you need to achieve load balancing then that is something you are going to have to live with, and can the application infrastructure deal with the effect of stranded messages?
| RocknRambo wrote: |
3. Client to Queue Manager
a. Is the client connection to the queue manager - a better option Vs QM to QM ? |
Removes the transmission queue 'bottleneck' issue, but a single queue manager is a bottleneck if you lose it, and as for clustering can the application infrastructure deal with the effect of stranded messages if you are using multiple queue managers and you lose one?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Dec 07, 2009 3:02 pm Post subject: Re: MQ Connectivity |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| RocknRambo wrote: |
We have a requirement to establish MQ connectivity between the two data centers on a dedicated & secured pipleline, and came up with few options:
Peak, message volume is 125K/Sec
1. Queue Manager to Queue Manger
a. Having one transmission queue will be bottleneck in case of the connection failure.
b. Multiple transmission queues, manual load balancing with high volume transactions, perception of the admin team is sender/receiver channels are unreliable, often shutsdown. is this a true statement ?
|
No, MQ is generally more reliable than the network. If channels are seen to often shut down, investigate the reason. Hint: network or incorrect setting of DISCINT.
| Quote: |
2. MQ Cluster repository
a. Single transmission queue, could be a bottleneck
|
No matter how many transmission queues there are, they all share the same MQ and systems resources, so the overall throughput of one xmitq versus many will not be hugely different.
| Quote: |
3. Client to Queue Manager
a. Is the client connection to the queue manager - a better option Vs QM to QM ? |
No. Client channels are inherently more unreliable than sdr - rcvr channels. They are also much slower as every put / get is a synchronous operation (unless some new MQ v7 features are used -- but these offer a lower level of service).
_________________
Glenn |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Dec 07, 2009 3:23 pm Post subject: Re: MQ Connectivity |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| gbaddeley wrote: |
| Quote: |
2. MQ Cluster repository
a. Single transmission queue, could be a bottleneck
|
No matter how many transmission queues there are, they all share the same MQ and systems resources, so the overall throughput of one xmitq versus many will not be hugely different. |
I'll disagree here. There are many variables of course, but supposing there are plenty of resources, MQ will offer a very good isolation between queues. Once two queues are "open" there is very little indeed that would cause two separate apps using them to contend for shared resources. I would suggest the more important question is the network bandwidth and the ability of the network to multiplex the variety of connections involved.
| RocknRambo wrote: |
3. Client to Queue Manager
a. Is the client connection to the queue manager - a better option Vs QM to QM ? |
The two are not comparable in the least. Maybe I misunderstand but I can't see any useful comparison to be made between client channels and message channels re. performance. |
|
| Back to top |
|
|
| RocknRambo |
| Posted: Mon Dec 14, 2009 9:23 am Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
Thanks for sharing your thoughts/experience.
Will there be any doc/article differentiating Pros/Cons on the client connections to QM Vs QM to QM. One point taken is the SLA, client connections are slower than SNDR/RCVR channels.
-RR |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
