| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Performance impact for remote administrative database |
« View previous topic :: View next topic » |
| Author |
Message
|
| hopsala |
 Posted: Sun Jul 05, 2009 12:09 pm Post subject: Performance impact for remote administrative database |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Hi all,
There are basically two options for the broker's administrative database - you can either install it locally or remotely. In both cases the broker connects to it via ODBC, so it's almost transparent configuration-wise.
According to the literature, the broker database is used for the following: static administrative data (flows, EGs, message sets and the like), aggregation messages, timer data and pub/sub retained publications. For each of these, I was wondering what the performance impact is for working with a remote administrative db, assuming a reasonable tcpip connection.
I'm especially interested in static data - let's say I have a production broker who does not have aggregation, pub/sub or timer nodes, how will using a remote administrative db be different from using a local one? Does any one have any actual performance data on this, or some sort of estimate? When exactly does the broker access the db, and how complex are the queries/updates involved?
I did see some mention in the lit that message flows and EGs are read from the db on start time and cached in memory; I also remember something about message sets being cached when they are first used. But say I have too many message sets to store in memory all at once, will a sort of paging mechanism kick in when memory runs out?
My apologies for the semi-long post. I'm trying to collect as much data as I can about a relatively non-documented issue.
Much obliged! |
|
| Back to top |
|
 |
| kimbert |
| Posted: Sun Jul 05, 2009 12:30 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| But say I have too many message sets to store in memory all at once, will a sort of paging mechanism kick in when memory runs out? |
I will let others comment on the other questions, but I can give a definitive answer to this one. There is no such paging mechanism. Message sets are cached per execuction group. They are loaded into the cache when first used, and are never unloaded until the execution group is stopped. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jul 05, 2009 12:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
There is one big thing you did not mention when talking about moving the DB off the box. Assuming you run multiple brokers how will that play for maintenance when the DB needs to be maintained. Does that mean the brokers are all down?? There is a reason to keep everything as a unit on the same box... Should any of the components fail on one box the others are'nt affected... Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 06, 2009 4:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| There is one big thing you did not mention when talking about moving the DB off the box. Assuming you run multiple brokers how will that play for maintenance when the DB needs to be maintained. Does that mean the brokers are all down?? There is a reason to keep everything as a unit on the same box... Should any of the components fail on one box the others are'nt affected... Enjoy |
The other side of this is: why does a message broker administrator need to be a database administrator as well? Why does a message broker machine need to have enough disk on it and enough capacity to run a full database server as well? |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Jul 06, 2009 10:22 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
@Jeff and Saper:
Well, on the one hand having one logical unit (broker-db) on two machines does mean more maintenance downtime, and probably more communication-related problems; however, as Jeff said, if the server will be busier running both the db and the broker, that also means an increase in server failures - I've learned long ago that higher throughtput means higher failure rates.
In my case, I have a client whose database team only supports Solaris machines, and whose MQ team only works with AIX. What I'm trying to figure out, is whether the performance degredation of a remote db will be severe enough to justify twisting any of these teams's arms. There are also several rather strict site technical standards involved, which I'll have to break if I use a local db.
@kimbert - thanks, that's good to know.
Well, I'm still far off from being able to resolve my dilema. I'm worried that even performance tests won't do the trick, and I'd much rather get the specification than try to backwards-engineer it.
Any other input, anyone? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 06, 2009 11:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
My 2 cents, and following on from the comment of fjb_saper:
Current site is a big user of WMB, with a lot of aggregation, some complex flows and a fair throughput (though not large). For political reasons they have 2 and only 2 db servers, one for prod, one for everything else. They're both on Solaris boxes the size of houses, with as much CPU and memory crammed into them as possible, arranged Active/Active with the dev box providing failover for prod.
Database maintenance is a pain. The database team stopped asking about 3 years ago if they could take the machine down, and now just announce dowtime & measure the level of complaints. If they don't get a critical mass of development protest, they do it.
One view, other views equally valid, etc, etc.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
