|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
WMQ big messages over 4MB, go through other MQ cluster? |
« View previous topic :: View next topic » |
Author |
Message
|
gerimqseries |
Posted: Tue Apr 16, 2013 5:52 am Post subject: WMQ big messages over 4MB, go through other MQ cluster? |
|
|
Apprentice
Joined: 03 Aug 2009 Posts: 30
|
Dear Masters,
this is the situation:
We have 4 QManagers in the MQ cluster (CLUS1), which has cluster queues as well (QUEUE.CLUS1).
The client has to send some 'big messages' (over 4MB) to it (QUEUE.CLUS1), but we do not want to send it through the 'small messages' cluster, not slow down small messages.
(The client must not cut or segment messages, it must send the whole thing in one piece)
It is an acceptable solution to create a 'big message' (CLUS1.BIG) cluster, and set the whole things' MAXMSGL parameters to 100MB?
Or we have to give up the 4 node cluster, and create remote q definitions, big message xmitqs, channels point to only 1 node?
Thank You! |
|
Back to top |
|
 |
exerk |
Posted: Tue Apr 16, 2013 6:07 am Post subject: Re: WMQ big messages over 4MB, go through other MQ cluster? |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
gerimqseries wrote: |
It is an acceptable solution to create a 'big message' (CLUS1.BIG) cluster, and set the whole things' MAXMSGL parameters to 100MB? |
Creating a second, overlapping, cluster with separate CLUSSDR/CLUSRCVR channels will be of little utility unless you are using an appropriate version of WMQ, i.e. one that supports separate cluster transmission queues, as the larger messages on a single cluster transmission queue may impact the relay of smaller messages.
gerimqseries wrote: |
Or we have to give up the 4 node cluster, and create remote q definitions, big message xmitqs, channels point to only 1 node? |
The question is just how many instances exist of the queue that will receive these 100MB messages? If only one queue manager hosts the queue(s) then it could be argued that the clustering paradigm of multiple target instances is 'broken' - notwithstanding the argument that queue manager clustering can also be used as a method of reduced configuration administration (not a view I subscribe to). _________________ 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 |
|
 |
PeterPotkay |
Posted: Tue Apr 16, 2013 6:41 am Post subject: Re: WMQ big messages over 4MB, go through other MQ cluster? |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
exerk wrote: |
gerimqseries wrote: |
It is an acceptable solution to create a 'big message' (CLUS1.BIG) cluster, and set the whole things' MAXMSGL parameters to 100MB? |
Creating a second, overlapping, cluster with separate CLUSSDR/CLUSRCVR channels will be of little utility unless you are using an appropriate version of WMQ, i.e. one that supports separate cluster transmission queues, as the larger messages on a single cluster transmission queue may impact the relay of smaller messages.
|
I agree that the ability to have seperate cluster transmit queues as of MQ 7.5 would be nice to use in this scenario. But would there really be any large impact if both clusters used the SYSTEM.CLUSTER.TRANSMIT.QUEUE? The CLUSSNDRs will be doing get by Correl IDs against the S.C.T.Q. looking for their particular messages. The size of these messages should not impact this selection process I think.
Now, if the messages are so big that the transmission of them really slows down, causing the queue depth of the S.C.T.Q. to rise, then yes the selective gets would slow down as they have to sort through a deep transmit queue.
If the volume of the big messages is low, then I think there would be some benefit even before MQ 7.5 (and its cluster specific transmit queues option) to get those big messages onto their own cluster channels, if the felling is that even an occasional big fat message moving over the regular cluster channels would impact the smaller more timely messages. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
gerimqseries |
Posted: Wed Apr 17, 2013 12:23 am Post subject: |
|
|
Apprentice
Joined: 03 Aug 2009 Posts: 30
|
I forgot to tell the MQ version, this is: 7.0.1.*
Quote: |
PeterPotkay: The CLUSSNDRs will be doing get by Correl IDs against the S.C.T.Q. looking for their particular messages. The size of these messages should not impact this selection process I think. |
I agree with you
Quote: |
PeterPotkay: Now, if the messages are so big that the transmission of them really slows down, causing the queue depth of the S.C.T.Q. to rise, then yes the selective gets would slow down as they have to sort through a deep transmit queue. |
"They" said: there will be only 1 message per day in the beggining. I think, there will be more, but then we will upgrade MQ to 7.5
Quote: |
PeterPotkay: If the volume of the big messages is low, then I think there would be some benefit even before MQ 7.5 (and its cluster specific transmit queues option) to get those big messages onto their own cluster channels, if the felling is that even an occasional big fat message moving over the regular cluster channels would impact the smaller more timely messages. |
That is what I want.
Do You know any software/solution, how to measure the speed of messages when big and small messages goes through a QManager at the same time? Example: put time, get time?
Thank You. |
|
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
|
|
|
|