| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Strategy for number of queue managers |
« View previous topic :: View next topic » |
| Author |
Message
|
| twegmann |
 Posted: Fri Apr 05, 2002 1:23 pm Post subject: |
 |
|
Novice
Joined: 09 Aug 2001
Posts: 23
Location: New Jersey
|
We are following a strategy of deploying a specific queue manager for each application we are trying to integrate. Some of these apps run on the same box, so we will end up with multiple q mgrs running on a given server (4 max). We did this from an availability perspective(if a q mgr stops, only that application is affected).
An 'expert(?)' told me that it was a better strategy to deploy a single queue manager per physical server because it reduced adminstration.
Can anyone advise on the relative merits of each strategy ? |
|
| Back to top |
|
 |
| kolban |
| Posted: Fri Apr 05, 2002 8:38 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Would you create a separate database for each set of applications? Maybe ... but probably not. In my experience, queue managers are ultra hardy animals. As long as you give them minimal care and feeding, you should have no troubles. MQSeries from IBM has been around since 1993 ... all the kinks have been ironed out ... especially in the core functions. As new functions are added in each release, these are the ones that I become cautious of until they have proven themselves.
It is true that increasing the number of queue managers increases the administration cost. It will also increase the resource consumption on that machine. MANY applications can happily run against the same queue manager without contention. My $0.02 would be run few queue managers. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Sun Apr 07, 2002 1:07 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well heres my 0.02 if you run multiple queue managers you will see some minor
application performance. The big benefit I see is buy seperating them you isolate the application from each other and it makes it easier to restart/test/debug any application issue's because you wont be affecing the other applications.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 09, 2002 9:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
OK twegmann, now you have 6 cents total!
My opinion is that as long as none of your apps will be running with the fastpath option set on the MQCONNX call(which introduces the possability of 1 app taking out the QM), use 1 queue manager per box, and make him the default.
As your apps get moved from machine to machine, you never need to code the queue manager name on a MQCONN call. This is nice since there is no need to change code as the app moves from the DEV server to the QA one to the production one. We have Queue Managers with hundreds of queues, works great. If it gets to the point where the queue manager can't keep up, I would guess you would be close to the point where the hardware couldn't keep up either, and you would need another box anyway, with it's own QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
