| Author |
Message
|
| satya2481 |
 Posted: Fri Jul 08, 2011 1:04 am Post subject: Redice MIPS - Message Broker ESQL Coding Standards |
 |
|
Disciple
Joined: 26 Apr 2007
Posts: 170
Location: Bengaluru
|
Hi All,
We are having a service developed in MQSI 2.1 version broker. This flow is been migrated to WMBV6.1 and will be placed in MainFrame Broker environment.
Without any modifications in the code MIPS coming around 250. The requirement is to bring down this MIPS value from 250 to atleast 50.
Could anyone share the information or standards to follow to bring down the MIPS.
Thank You
Satya |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Jul 08, 2011 1:32 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Moving this to the Broker forum...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jul 08, 2011 2:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
set lowmips=1 ... 
The more recent the broker version, the fewer MIPS it should consume.
I don't use z/OS (more's the pity) but there should be an IBM performance report support pac with some advice.
I have seen web articles on improving message flow performance, these will apply to any platform. Read these. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 08, 2011 4:08 am Post subject: Re: Redice MIPS - Message Broker ESQL Coding Standards |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| satya2481 wrote: |
| This flow is been migrated to WMBV6.1 and will be placed in MainFrame Broker environment. |
What platform was it running in before? Did it perform badly there or did performance not matter because you weren't charged for CPU there?
| satya2481 wrote: |
| Without any modifications in the code MIPS coming around 250. The requirement is to bring down this MIPS value from 250 to atleast 50. |
That's a significant reduction.
| satya2481 wrote: |
| Could anyone share the information or standards to follow to bring down the MIPS. |
Good code is good code, on mainframe or not.
3 tips (4 if you include not double posting; if you post in the wrong section just ask for the thread to be moved):
1) Make sure you leverage all the features built into v6.1 that you had to code for in v2.1
2) Use XMLNSC not XML - the XML domain still works in v6.1 but XMLNSC is significantly more efficent
3) Make sure you've identified where the code is burning MIPS before you start - you'll get a better return on your effort if you start on the hotspots
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 08, 2011 4:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| set lowmips=1 ... |
Is that the same class of flag as the Windows NoCrash=1? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Jul 08, 2011 4:28 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 08, 2011 4:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| You may find better luck on a platform other than z/OS. |
Again, you assume everyone has your ability to make sites switch platforms.
Again, you assume everyone has your ability to refuse work rather than being stuck with the tasks they're assigned.
Again, you're not answering the question being asked in any helpful way. You're like a doctor treating someone with a broken arm by advising them not to fall over and break it.
Again, you're pushing your crusade for the world to move onto AIX Power7 (or at least non-z/OS) in poster's faces.
Stop this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Fri Jul 08, 2011 5:44 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
You will need to change the flow (assuming you can take advavtange of the nodes listed below, and your shop makes use of zAAPs):
| Quote: |
Reduced cost of ownership
These improvements mean that existing users will see significant benefit from moving to Message Broker V6. Similarly, new users can be confident that z/OS broker-based solutions deliver a high-performance solution with excellent value for the money.
Using zSeries Application Assist Processor (zAAP)
You can now offload machine instructions generated by the Java Virtual Machine to dedicated processors called zAAPs. A zAAP costs significantly less than a regular central processor, and zAAP capacity is not included in MSU capacity. Therefore you can offload Java-based applications without any increase in software costs. zAAP is available with z/OS V1.6 or later.
Message Broker V6 has several features that directly exploit zAAP technology, namely the Java Compute node, XLST node, and JMS Real-time and Multicast nodes. Therefore message transformations in Java and XSLT may be able to offload a significant percentage of their workload. Message distribution using JMS real-time and Multicast transports will similarly benefit.
The Java Compute node has been designed to cater for the needs of integration developers who wish to use Java as a transformation and routing language. All transformation logic written in these nodes is eligible for offload to zAAP. (However, parsing operations are still performed by non-Java components and are not eligible for offload). The exact offload amount depends on the amount of transformation logic compared to the amount of parsing. For simple messages that don't require too much parsing, or relatively complex message transformations, the zAAP offload should be significant.
XSLT processing, while requiring an XML input message, is increasingly significant. Because processing is entirely in Java, offload ratios as high as 80% have been observed in lab tests using this node. JMS Real-Time and Multicast components can be fully offloaded to zAAP, which means that non-queue-based pub/sub messaging involving a z/OS broker can benefit significantly. Also, the Configuration Manager is implemented in Java, so on z/OS, all of its CPU processing can be offloaded to zAAP.
50% Performance Improvement with V6
Message Broker V6 is an industry leader in high-performance transformation and routing. But the CPU cost associated with these functions is significantly higher than with traditional data processing. For example, parsing large XML documents requires lots of processor cycles. To dramatically reduce cost of ownership, IBM has made significant performance improvements in Message Broker V6 compared to previous versions.
Message Broker V5 and V6 were compared using a comprehensive range of tests involving different messaging styles, protocols, and message formats. In customer-oriented end-to-end messaging scenarios, messaging throughput increased by 50% with Message Broker V6. These reductions in processing costs are in addition to benefits from zAAP offloading when using broker Java components. The improvements were achieved without external product interface changes, so if you migrate from a previous release, you should see these performance improvements for existing message flows without changes to integration logic.
These improvements have been achieved without external product interface changes, meaning that users migrating from previous releases will see an improvement for existing message flows without having to change their integration logic. These performance improvements result from work in the following areas:
Parser improvements: Industry based (e.g. SWIFT) and record based (COBOL/C) parsers have seen improvements by up to a factor of four
ESQL improvements: Implementation has been thoroughly analysed and their implementation improved by an average factor of two
Locking and scalability: A significant reduction in CPU cost and wait times in multiprocessing environments
Aggregation implementation: MQ based implementation rather than database to give up to four times improvement in throughput
zSeries and z/OS technology exploitation
XML Toolkit
Exploitation of Unicode conversion services and native hardware features
IEE754
Exploitation of native hardware IEE754 floating point operations
New Compiler algorithms
Generation of machine instructions for latest hardware ARCH(3) and above
Aggressive compiler optimization OPT(3)
64 bit multiply and divide algorithm enhancements
Native Unicode string generation
z/OS 1.5 or above
Complete XPLINK exploitation of LE, Broker, JVM and ODBC
|
Source:
http://www.ibm.com/developerworks/websphere/library/techarticles/0604_odowd/0604_odowd.html |
|
| Back to top |
|
|
| satya2481 |
| Posted: Thu Jul 28, 2011 7:34 pm Post subject: Resolved |
|
|
Disciple
Joined: 26 Apr 2007
Posts: 170
Location: Bengaluru
|
Hi All,
Thank you for your replies...
I am able to bring down the MIPS results... after recoding the entire flow...
I have used below features...
1. Reference variables where ever looping or multiple field mappings are involved
2. Used SELECT statement instead of CARDINALITY
3. Removed series of Compute nodes and the code is written in a single compute node
4. RCD node is used for message validation instead of performing in the code
Thank You
satya |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jul 29, 2011 2:02 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
What does this mean?
| Quote: |
| RCD node is used for message validation instead of performing in the code |
|
|
| Back to top |
|
|
|
|
