| Author |
Message
|
| er_pankajgupta84 |
 Posted: Mon Jan 09, 2012 1:45 pm Post subject: Capacity Planning for WMB on Zos |
 |
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Jan 10, 2012 5:44 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 10, 2012 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| z/OS is the last platform you want to use for WMB. |
Not this again. We've been here.
Remember that the OP may not be in your exaulted position of demanding his site buy a POWER7 platform to run WMB. Or maybe they're trying to integrate 2 Z/OS applications and want to avoid the network.
Or anything.
The OP's trying to find a book. He doesn't need to be told he's wrong & buy a Kindle.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 10, 2012 6:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| z/OS is the last platform you want to use for WMB. |
Not this again. We've been here.
Remember that the OP may not be in your exaulted position of demanding his site buy a POWER7 platform to run WMB. Or maybe they're trying to integrate 2 Z/OS applications and want to avoid the network.
Or anything.
The OP's trying to find a book. He doesn't need to be told he's wrong & buy a Kindle. |
Armed with the right information, a power player could persuade the management to evaluate the decision. The meritorious information of cost-per-transaction cannot be argued.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 10, 2012 6:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Armed with the right information, a power player could persuade the management to evaluate the decision. The meritorious information of cost-per-transaction cannot be argued. |
Again, we've been here.
But I am interested by your new assertion that management can be swayed by facts, and a well reasoned case backed by facts & a cost/benefit analysis can change architecture & strategy decisions.
Not here because this is getting way off topic, but consider running a poll along the lines of:
How many people have presented a case to management illustrating that a current management decision is not cost effective / technically ridiculous / strategically unwise, with supporting facts, and have effected change?
How many people in this situation have been told post-presentation, "Yes, that's probably the case but we're too far down the road to change / we'll need to address this in the next phase / it's an audit requirement to do it this way / we're too close to implementation to change direction now"?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 10, 2012 6:36 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You have valid points, dear Vitor. And I've shared the Aprils Fools posts with my friends, who laughed as loud and hard as I did.
The OP seems to be collecting capacity planning information. One could postulate the capacity planning information would be used to formulate business strategy going forward.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 10, 2012 6:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| One could postulate the capacity planning information would be used to formulate business strategy going forward. |
One could. One could likewise theorise that he's just trying to work out how much larger an existing broker needs to be for a planned new load (or perhaps if it needs to be larger)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Jan 10, 2012 7:06 am Post subject: Not Again.. |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Guys..
we are deviating from the actual topic..
lancelotlinc - I have read the other post having 100s of reply .. on power7 vs ZOS.
I am not asking for performance reports of Zos and option of hardware change.
I have read the performance report that you suggested already.
My primary aim is to design a capacity model which can tell us the bare minimum from a broker's perspective for a new project.
I am specifically looking for information about what all things do I need to consider while installing a broker for production. For example - Number of brokers, EG's jvmheapsize, cores, cpus, memory etc..
Basically I am looking for all the "Left hand side" of the equation and then later will fill the "Right Hand Side" based on the requirement and performace reports.
This kind of information is not limited to Zos but would be required for any system.
Only the "Right hand side" values will change from hardware to hardware.
For example: for Zos I may need 40 Gb of memory to achieve some throughput for a given load on a given processor but Power7 may give the same throughput with 30Gb of memory with a weeker processor. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 10, 2012 7:49 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
WMB performance, especially for z/OS is directly related to message size. Can you describe your test case messages?
For example, the performance for 4,000 byte messages on z/OS is three times more efficient than for 2,000 byte messages due to the way the operating system manages memory pages.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jan 10, 2012 7:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's very hard to directly compare different platforms - especially between z/OS and the others.
Also depends if the "speciality" processors on z/OS are used - especially the Java engines (which I would assume is a good idea for WMB).
It really depends how the hardware costs are charged back to the project. If there is existing spare capacity the incremental cost may be zero. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Jan 10, 2012 8:11 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
This is good knowledge..
I appreciate.
We cannot use any other platform other than ZOS.. lots of politics..
So now with ZOS we need to do the optimal setting so that production system never dies..outages are easier to take....upgrades can be applied easily.
So far I can think of the following components that we need to consider and select appropriate value for them for an effective broker production system.
1. Number of core.
2. Number of processor.
3. Number of Broker.
4. Number of Execution group per broker.
5. Size of broker log.
6. Media used for broker log.
7. Max min heap size of each EG. (We have extensive java usage with use of different java frameworks)
8. Stack size.
Can you think of some other paramters like this...
Once we have all such paramters .. next step would be start assigning them value (based on load, msg size, througput req etc). |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 10, 2012 8:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| er_pankajgupta84 wrote: |
| So now with ZOS we need to do the optimal setting so that production system never dies |
Z/OS die? Never happens!
| er_pankajgupta84 wrote: |
So far I can think of the following components that we need to consider and select appropriate value for them for an effective broker production system.
1. Number of core.
2. Number of processor. |
I'd speak to your local system programmers (and your capacity planning team if it's a separate area). A Z/OS system doesn't have "cores" or "processors" in the sense a Unix box does. Irrespective of the underlying hardware, what you need to be concerned with here is the amount of resource assigned to the LPAR and how much of that resource the WLM is going to be giving your broker(s).
| er_pankajgupta84 wrote: |
| 3. Number of Broker. |
A question best phrased as "why do I want more than 1 broker". Typical aqnswers include "1 for Test, 1 for QA, 1 for Prod" rather than "3 in Prod".
| er_pankajgupta84 wrote: |
| 4. Number of Execution group per broker. |
See my point on resources above. Also consider why you'd have more than 1 EG on Unix & apply the same decision making process.
| er_pankajgupta84 wrote: |
| 5. Size of broker log. |
Not entirely relevant.
| er_pankajgupta84 wrote: |
| 6. Media used for broker log. |
I doubt you'll have too many choices.
| er_pankajgupta84 wrote: |
7. Max min heap size of each EG. (We have extensive java usage with use of different java frameworks)
8. Stack size. |
You need your sys progs. As I said above, z/OS doesn't allocate resource like other platforms, even though a z/OS JVM thinks it does.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Jan 10, 2012 8:43 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Thanks Victor,
| Quote: |
er_pankajgupta84 wrote:
So far I can think of the following components that we need to consider and select appropriate value for them for an effective broker production system.
1. Number of core.
2. Number of processor.
I'd speak to your local system programmers (and your capacity planning team if it's a separate area). A Z/OS system doesn't have "cores" or "processors" in the sense a Unix box does. Irrespective of the underlying hardware, what you need to be concerned with here is the amount of resource assigned to the LPAR and how much of that resource the WLM is going to be giving your broker(s).
|
By number of cores / Processor I meant what resources should be allocated to LPAR and how much eventually to Broker.
| Quote: |
er_pankajgupta84 wrote:
3. Number of Broker.
A question best phrased as "why do I want more than 1 broker". Typical aqnswers include "1 for Test, 1 for QA, 1 for Prod" rather than "3 in Prod".
|
This is typically number of brokers in production. Clusterred Queue would be used. Brokers may be on different LPARs.
My intension right now is not to get answers to these question. But just to accumulate questions. So that we can address them based on our need.
Is there anything else that should I consider ..? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 10, 2012 9:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| er_pankajgupta84 wrote: |
| Thanks Victor, |
 
| er_pankajgupta84 wrote: |
| By number of cores / Processor I meant what resources should be allocated to LPAR and how much eventually to Broker. |
Fair point, though LPAR resources are obviously global & both that & WLM settings are under the control of the sys progs due to their potential knock-on effects.
| er_pankajgupta84 wrote: |
| This is typically number of brokers in production. Clusterred Queue would be used. Brokers may be on different LPARs. |
If you're sharing between queue managers & LPARs be sure you're using a WMQ cluster and not a QSG. In your position I'd seriously consider that.
| er_pankajgupta84 wrote: |
| My intension right now is not to get answers to these question. But just to accumulate questions. So that we can address them based on our need. |
Again fair point; I was just trying to add some z/OS terminology to the debate! Many sys progs look pityingly at you when you talk about "cores" and "stack" but you clearly already have enough grasp to deal with this.
The other thing you should include in this is the size & tuning of the queue managers the broker(s) will be using. Proper use of storage classes & placement of page sets gains you a lot from a z/OS queue manager so be sure that however you've got the broker set up the queue manager is properly configured for your load.
And as always on z/OS think about security first not last. Get your RACF (or whatever) in place up front so at least you've got access set up & run your brokers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 10, 2012 9:09 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| er_pankajgupta84 wrote: |
1. Number of core.
2. Number of processor.
3. Number of Broker.
4. Number of Execution group per broker.
5. Size of broker log.
6. Media used for broker log.
7. Max min heap size of each EG. (We have extensive java usage with use of different java frameworks)
8. Stack size.
Can you think of some other paramters like this...
Once we have all such paramters .. next step would be start assigning them value (based on load, msg size, througput req etc). |
Could you describe the above parameters for your scenario ?
(based on load, msg size, througput req etc).
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
