| Author |
Message
|
| lancelotlinc |
 Posted: Mon Apr 02, 2012 11:54 am Post subject: |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| er_pankajgupta84 wrote: |
| @vitor - We have tested this several times with production load testing with multiple instance. (Tested under 47 TPS for hours) |
47 TPS is not load.
|
@er_pankajgupta84
Your client's z/OS system is only capable of 14 TPS. This load testing must not have been on the z/OS environment. Or, you are not using the client's load regression suite.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Apr 02, 2012 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Your client's z/OS system is only capable of 14 TPS. |
You've been told about this; your determination to throw out this apples-to-oranges comparison as fact is getting past a joke.
Stop it.
There's also nothing to indicate that the broker is on z/OS; it could be on POWER 7 with the DB2 on z/OS.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Apr 02, 2012 12:20 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| Your client's z/OS system is only capable of 14 TPS. |
You've been told about this; your determination to throw out this apples-to-oranges comparison as fact is getting past a joke.
Stop it.
There's also nothing to indicate that the broker is on z/OS; it could be on POWER 7 with the DB2 on z/OS. |
Vitor, I know this because I ran the performance tests on that system. I have personal and professional knowledge of this limitation.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 02, 2012 12:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Your client's z/OS system is only capable of 14 TPS. |
This is also factually inaccurate. A COBOL batch job running on z/OS is capable of far, far more than that. So a z/OS system can run at more than 14 TPS, depending on circumstance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 02, 2012 12:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Vitor, I know this because I ran the performance tests on that system. I have personal and professional knowledge of this limitation. |
On that system. If you can demonstrate that you've repeated the test on every z/OS system in the world, in every possible tuning configuration, I'll believe you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Apr 02, 2012 12:22 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| Your client's z/OS system is only capable of 14 TPS. |
This is also factually inaccurate. A COBOL batch job running on z/OS is capable of far, far more than that. So a z/OS system can run at more than 14 TPS, depending on circumstance. |
You are speaking on a subject for which you do not know. The 14 TPS limitation is due to the design of the message flows and the underlying hardware architetcure.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Apr 02, 2012 12:23 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| Vitor, I know this because I ran the performance tests on that system. I have personal and professional knowledge of this limitation. |
On that system. If you can demonstrate that you've repeated the test on every z/OS system in the world, in every possible tuning configuration, I'll believe you. |
No, I am only refering to the specific client's regression suite of tests. The client can approach 16 TPS before timeouts start to occur. The client can run 14 TPS reliably.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 02, 2012 12:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Vitor wrote: |
| lancelotlinc wrote: |
| Your client's z/OS system is only capable of 14 TPS. |
This is also factually inaccurate. A COBOL batch job running on z/OS is capable of far, far more than that. So a z/OS system can run at more than 14 TPS, depending on circumstance. |
You are speaking on a subject for which you do not know. The 14 TPS limitation is due to the design of the message flows and the underlying hardware architetcure. |
Read what I post, not what you think I post. A COBOL batch job has nothing to do with a message flow.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 02, 2012 12:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| No, I am only refering to the specific client's regression suite of tests. The client can approach 16 TPS before timeouts start to occur. The client can run 14 TPS reliably. |
So, as I'm tired of saying, post that your experience with your client is that the message flow can't exceed 14 TPS. Don't generalize it to all message flows with all clients, and don't say that non-WMB z/OS applications are similarly restricted.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Apr 02, 2012 12:50 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| No, I am only refering to the specific client's regression suite of tests. The client can approach 16 TPS before timeouts start to occur. The client can run 14 TPS reliably. |
So, as I'm tired of saying, post that your experience with your client is that the message flow can't exceed 14 TPS. Don't generalize it to all message flows with all clients, and don't say that non-WMB z/OS applications are similarly restricted. |
In this chain of posts, I am specifically referring to er_pankajgupta84's claim that the client can attain 47 TPS, which I know not to be true.
In other posts, I stand by my assertion, that for some message sizes, z/OS uses more CPU time than other platforms due to a z/OS architectural limitation. My opinion is reinforced by IBM published performance reports. You have the freedom to disagree with me, and I won't challenge you on it.
I respect your opinion and professional experience, Vitor. I would really like to collaborate with you and others to find the more definitive truth.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Mon Apr 02, 2012 1:14 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
My thread got hijacked again 
@lancelotlinc - I think you worked here quite a time back. I agree with you many things are broken here but all those can be sorted in a timely manner.
14 TPS at your time has now reached to 51 TPS. Fixing corrupted DAO did this. There is much more potential for improvement remaining.
Anyway, I agree with Vitor on all the generic comments he made.
It would be good if we stick to the dicussion related to the topic on a thread. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 02, 2012 3:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| er_pankajgupta84 wrote: |
| My thread got hijacked again |
And I apologise unreservedly 
| er_pankajgupta84 wrote: |
| It would be good if we stick to the dicussion related to the topic on a thread. |
Sound advice. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Apr 03, 2012 7:03 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I found this:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fas09970_.htm
Broker provides a feature to create the user defined node by extending MbNode. The link shows a public constructor defined in the class which extends MbNode, which to me indicates that it can be instantiated where ever required.
Is there any restriction to it or am I missing something? Does only broker is allowed to instantiate it?
Actually our requirement is to read the broker environment details (broker and EG names) to include in the log statements for uniquely identifying the EG specific Java logs. We are reading these details during the initiation. Once the values are read we are storing them in the static variables and de-referencing the BrokerEnvironmentDetails object. |
|
| Back to top |
|
|
| jlaisbett |
| Posted: Tue Apr 03, 2012 12:43 pm Post subject: |
|
|
Apprentice
Joined: 27 Nov 2009
Posts: 39
|
Just out of curiosity, how are you getting to the BrokerEnvironmentDetails class from your flows, is it via a compute node or a java compute node?
I haven't specifically come across something saying similar restrictions apply to MbNode but it uses JNI so there's definately potential for problems (not guaranteed to be problems but I wouldn't personally trust doing it). That's not to say such documentation doesn't exist, just that I haven't seen it.
I'm thinking you could just do it by using a common Java compute node that is at the begginning of each flow that needs the data, that java compute node simply reads the data straight from the broker API it has direct access to and stores it in static variables. I'm not entirely sure how your specific flows work but if you've got to go through compute nodes to get to your special class anyway there may be inherently safer ways to do it. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Apr 03, 2012 4:48 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
| We wanted to have broker & EG details within the common java framework (Non JCN). If we take the route of setting static variables within the first JCN and then access it in the common java framework then we need to modify all the existing FIRST JCN nodes not realistic at this moment. |
|
| Back to top |
|
|
|
|
