| Author |
Message
|
| ghoshly |
 Posted: Tue Feb 16, 2010 12:11 am Post subject: Performance analysis between Mapping Node and XSLT node |
 |
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
Hello,
I want to do a performance analysis for XSLT node against MB mapping node when we need to XML to XML transformation.You might say as earlier that "Its a question of debate of which transformation method to use". Its typically yes, and I want your view in one of my current scenario.
Message Broker V6.1 in AIX is in use.
Message size would be around 3KB to max 4KB with message volume of 29,214 daily.
Both input and output XSD would be available.
Customer do not want to go for Compute node option on the question of maintainibility of around 60 - 70 fields, so choice is narrowed between XSLT or Mapping node.
Most of teh mapping required in these interface is either straight forward mapping or based on some IF THEN ELSE condition.
In some earlier post we got some performace report on XSLT Vs ESQL but not the mapping node.
It was also mentioned that "using a mapping node is more efficient than an XSLT node" -- my question is it XML to XML transformation wise efficiency calculation or its because that unlike XSLT mapping node is capable enough to map between two structured tree structure even they are not xml....
Thanks for looking into it.. Happy to discuss if any further details is required.  |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Feb 16, 2010 9:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well you should have started by giving us the SLA for the flow.
With the number of messages / day and the size of the messages I see absolutely no problem either way.
The real question is what is your SLA here. Are you supposed to just be subsecond or should you be below 400 ms?
Also what parser do you intend to use, XMLNSC I hope?
Have some fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bprasana |
| Posted: Thu May 27, 2010 10:27 pm Post subject: Just revisiting this thread |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
We have a similar issue too. so wanted to evaluate performance for XSLT and ESQL too.
We have around 30-40 elements and 1sec time to do the transformation.
But can the xslt node 'map' elements from headers and Environment trees like the Compute Node?
What benefits do we have if we use ESQL that is not there is XSLT and vice versa?
What I read from the article below is that XSLT is slower that ESQL. ( Correct me if I am reading it out of context)
http://www.ibm.com/developerworks/websphere/library/techarticles/0608_piper/0608_piper.html
here's the extract
| Quote: |
Performance, efficiency, and cost issues
Performance, efficiency, and cost issues include asset reuse, speed and cost of development, and runtime performance. The ability to reuse an asset such as an extensible stylesheet can reduce development costs, but may impact run-time performance, depending on the type and complexity of processing involved, since performance of an extensible Stylesheet is generally slower than a hand-coded implementation in ESQL or Java. If message throughput is a primary consideration, ESQL or Java is probably a better choice for your processing logic.
|
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 28, 2010 2:14 am Post subject: Re: Performance analysis between Mapping Node and XSLT node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ghoshly wrote: |
| Customer do not want to go for Compute node option on the question of maintainibility of around 60 - 70 fields, so choice is narrowed between XSLT or Mapping node. |
This particular criteria is not valid. Every change made to either the field definition in a given message or to the mapping between two specific fields is going to be "the same" amount of work to implement.
If the change made is to add a field to either the message being mapped FROM or the message being mapped TO, but no *use* of this field is made (i.e. a new field is added to the input message but is not used by the output message and does not need to be manipulated).... then the transformation logic remains unchanged and only the message definition needs to be updated. This is true regardless of what choice is made for transformation.
If a change is made that requires the transformation logic to change, then the amount of work required to make that change and test that change is going to be roughly the same in all transformation methods available. You need to manipulate a map, you need to edit an XSLT, you need to edit the ESQL, java or PHP code... And then you need to deploy and test and validate and promote.
If customer doesn't want to use ESQL because it's "non-standard" and customer doesn't want to use Java because "it's complicated", then customer might consider PHP.
In general the only reason to use XSLT is because you have existing stylesheets that need to be used, or you otherwise already have a large investment in using XSLT for transformation. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Fri May 28, 2010 4:33 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Quote: |
| If customer doesn't want to use ESQL because it's "non-standard" |
Why do some groups get so scared of ESQL? For basic transformation work is can be very quick to develop and easy to maintain. |
|
| Back to top |
|
|
| rbicheno |
| Posted: Fri May 28, 2010 8:58 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2009
Posts: 43
|
Mapping node is for ease of use not really performance, although the supportpac IA9Y will help somewhat, you then lose your map and are working direct with ESQL again.
For me XSLT offers decent performance (better than mapping, but a tad slower than esql and java), its an open standard with lots of tools (even mapping tools) to support it, and it means i can get other people to code transformations and test them without any WMB setup required, they just use one of the many xml tools to apply the xslt to the xml doc and check the output is right. I like to leave the stylesheet on the file system (not in the bar file) then you can update the transformation without even needing to redeploy a flow. You can also dynamically choose the stylesheet required for a transformation on the fly in your flow by setting the local env which also makes it very flexible.
Each technology has its place, i still use Java and ESQL too in many places. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri May 28, 2010 9:05 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| joebuckeye wrote: |
| Quote: |
| If customer doesn't want to use ESQL because it's "non-standard" |
Why do some groups get so scared of ESQL? For basic transformation work is can be very quick to develop and easy to maintain. |
The answer is that all they know is Java or even .NET. Very few people know SQL let alone ESQL these days.(much like CICS gurus eh?)
As you say, it is easy to develop very efficient code with ESQL.
BUT BUT BUT, you put a Java programmer into an ESQL only environment and then look at the quality of the ESQL they write.
ESQL is not one of those cool/hip/sexy languages. Much like my other favorite dev language namely Pascal.
PErhaps this need to be cool is why some companies develop apps for the cool, hip iPhone and ignore the Android platform but that is getting off topic.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| bprasana |
| Posted: Fri May 28, 2010 9:48 am Post subject: |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
So XSLT is slower that ESQL?
Just to make this situation little more complicated:
Our customer has bought a WDP license and need an option to make the migration from WMB trasnformation as easy as possible.
What would you choose? ESQL or XSLT? - For records, there are not existing XSLTs.
Also what other advantage(other than portability) do we have if I use XSLT node?
Regards,
bprasana |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri May 28, 2010 10:30 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| bprasana wrote: |
So XSLT is slower that ESQL?
|
Not in every case. There are some transformations which are ideally suited to ESQL. On the other hand, there are some which are more suited to XSLT.
In one situation, the ESQL was a real dogs breakfast. The XSLT solution was far more elegant, faster and more maintainable.
It depends....
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
