| Author |
Message
|
| rxm8778 |
 Posted: Wed Jan 23, 2008 1:32 pm Post subject: |
 |
|
Apprentice
Joined: 15 Sep 2005
Posts: 37
|
Thanks again I think it is just time for me to go out on a test environment and experiment with all this. 
I was not aware that more than one cluster receiver channel could be created to increase throughput...
Neither was I aware that I could manually define a cluster sender channel to point to a queue manager other than one of the full repository in other increase throughput...
But again nowhere in the cluster manual does it say you can't or shouldn't do any of this either!
Last edited by rxm8778 on Wed Jan 23, 2008 1:45 pm; edited 1 time in total |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Jan 23, 2008 1:40 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rxm8778 wrote: |
| PeterPotkay wrote: |
| Use stacked clusters and there won't be a maybe. The smaller messages will not be impacted by the bigger ones because each will be serviced exclusivly by their dedicated channel. |
Over here most if not all our queue managers are part of a cluster to begin with. My only problem with stacked cluster would be that each time a new project wants to send larger messages to a queue manager, and we have concerns that it might affects remaining smaller message traffic to that same queue manager, we would have to create/stack a cluster on top of the larger cluster just for that new traffic. Wouldn't this overall increase the administrative and mainteance work that cluster is meant to reduce?
|
Why would you need to make a new stacked cluster for each new project? Just create 2 stacked clusters. Tune the channel parameters in each cluster to suit either a few big slow messages or lots of small fast ones. Anytime a new app comes into the mix decide what cluster (1 of 2) their queues go to.
You could get nuts with this and make 12 different stacked clusters but why bother. Its to much work and the benefit is negligible. 2 is enough to keep the big messages from impeding your small timely ones.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 23, 2008 1:41 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think the intent of 12 stacked was to keep Big messages from APP A from impacting Big messages from App B...
Which leads to one cluster per app, massively overlapped... which leads to chaos and PMRs.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 23, 2008 1:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
On the flip side, nothing says you can't create an additional (manually defined) clussdr from QMA to QMB, so that you only have additional throughput on that one leg, rather than everywhere. |
I'm not so sure this would work. Manual cluster senders to a full repository are only every used once during the initial introduction of that QM to the FR*. After that the Automatic Cluster Sender is always used. I would think the same thing would happen for PR to PR. You might be able to define a manual CLUSSNDR from a PR to a PR (contrary to cluster best practices) but won't the cluster just ignore it and use the automatic CLUSSNDR instead?
* and they are also used if you issue the REFRESH command with the REPOS(YES) option, which in effect is reintroducing the PR to the cluster as if for the first time.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 23, 2008 1:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
I think the intent of 12 stacked was to keep Big messages from APP A from impacting Big messages from App B...
Which leads to one cluster per app, massively overlapped... which leads to chaos and PMRs. |
Agreed. If that's the case you have a classic contention issue requiring dedicated hardware for each app, if they are so invasive on each other.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 23, 2008 1:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| I'm not so sure this would work. Manual cluster senders to a full repository are only every used once during the initial introduction of that QM to the FR*. After that the Automatic Cluster Sender is always used. I would think the same thing would happen for PR to PR. You might be able to define a manual CLUSSNDR from a PR to a PR (contrary to cluster best practices) but won't the cluster just ignore it and use the automatic CLUSSNDR instead? |
Dang.
I knew I should have double-thought that.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
