| Author |
Message
|
| novice |
 Posted: Wed Aug 09, 2006 2:17 am Post subject: best practices for wmq and wmb on high-sized servers |
 |
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
hi everybody!
what expierence ist out there with wmq and wmb on very big servers?
i'm doing a capcity planning for wmq, wmb. the results are, we'll probably need a mainframe with up to 50 cpus!!!
how to place wmq and wmb on such a plattform?
how to scale? scale-up vs. scale-out?
one or n queue managers?
wmq cluster?
shared queues?
broker domains?
lot of questions!
any expierence or information with wmq and wmb on z/OS would be great. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Aug 09, 2006 2:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We run WBIMB v5 on a 12-CPU AIX platform. We only ever used all the CPUs during an initial intensive migration phase.
For very CPU intensive broker designs - I would question your message flow design first - there must be a way to optimise it.
It seems very unlikely that you will actually ever need 50 CPUs - I think the current z-Series supports only 32 anyway. You might benefit from the ZAAP processors though. |
|
| Back to top |
|
|
| novice |
| Posted: Wed Aug 09, 2006 2:45 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
yes, of course! before scaling an application, it has to be optimized.
we did the capacity planing based on the perfromance reports of ibm... accroding them it's not possible to achieve better results.
the need for so much hardware is because of the assumed big, big, big workload.
on z9-Hardware it's possible to have up to 54 cpus |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 09, 2006 3:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You always need a broker domain - because a broker domain is a configMgr and you always need a configmgr.
You don't want to attempt this kind of workload on a single broker.
That means more than one queue manager. For this kind of load, you probably need an HA solution, and there isn't a much better HA solution than shared queues on z/OS.
If you're even considering spending the money to buy a z machine with 50+ CPUs, you should be spending the money to engage IBM services for implementation and design as well.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| novice |
| Posted: Wed Aug 09, 2006 3:53 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
that's right! if we really gonna spend so much money in hardware, it would be careless not to take an ibm consultant. it's as well already planned. just want to look ahead.
shared queues on z/os is something great. the problem at this is the restriction of message size: 63 KB. with wmq v6.0 there isn't anymore this restriction, because messages that are bigger than 63 KB are written to db -> accoriding ibm specialists a performance degradiation of factor 4 is expected. not very nice |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 09, 2006 4:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What are your performance goals, anyway?
How big is the typical message, how many do you expect to process an hour or minute or second....
Even without using queue sharing groups, you can start multiple LPARs on Z, each with their own qmgr and broker and then MQ cluster these and workload balance as you need (especially with MQv6).
You might even be able to do some autonomic kinds of things, where z will bring LPARs on or off line to meet demand.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| NSJ |
| Posted: Wed Aug 09, 2006 4:42 am Post subject: |
|
|
Novice
Joined: 06 Jul 2005
Posts: 12
|
| Have you considered using Datapower integration appliance from IBM. Its a very powerful transformation engine. Including it as a part of the integration solution may increase performance. |
|
| Back to top |
|
|
| novice |
| Posted: Wed Aug 09, 2006 6:05 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
don't be frightened. but the system should be able to perform 45 GB per hour. transforming and routing messages.
once the costs of such a system are known, the requirements will be probably slowed down. i hope so.
sadly, most of the messages will be bigger than 63 kb.
i guess aswell that it's appriopate to scale out: multiple LPARs with their own queue manager and broker. the question arrives than how many cpu per LPAR or till when to scale up one LPAR and when to start doing scale-out with multiple LPARs and mq cluster.
another question would be what's actually the difference of having multiple instances of wmq/wmb on different LPARs or just on one LPAR? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 09, 2006 6:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Messages are usually bigger than 63k. Usually bigger than 1Meg? 10Meg?
The performance curve changes at various points. The average size of the message will affect things like how many instances of your flows you need to ensure that you process at the rate you need.
45Gb/hour = how many messages?
I don't know about on Z, but in general it's better to have one broker per machine (lpar) and one queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| novice |
| Posted: Wed Aug 09, 2006 6:57 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2005
Posts: 37
|
most of the messages are bigger then 63 KB but not bigger then 250 KB.
any z/OS-specialist here? |
|
| Back to top |
|
|
| KeeferG |
| Posted: Wed Aug 09, 2006 7:55 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
For distributed I used to recommend sticking to around 5 CPUs per broker/queue manager and workload balancing using MQ clustering. This gives a predictable and scalable architecture. With this approach we have had systems processing 20,000+ messages per second.
Obviously this is dependant on flow performance so each flow should be perfomance tested to determine how many instances of each flow are required.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
|
|
