| Author |
Message
|
| kotagiriaashish |
 Posted: Mon Jan 30, 2012 6:41 am Post subject: MB8 Mapping Node slow on Debug.. |
 |
|
Disciple
Joined: 06 Aug 2011
Posts: 165
|
I have red the posts in this forum and realized that Compute node Rules over Mapping Node... But what the heck?? In V8 too... a simple message takes atleast 2 to 3 seconds on debug... without any logic [only simple mapping...] is there something i am missin or the mapping node itself is a big bummer 
Last edited by kotagiriaashish on Tue Jan 31, 2012 5:44 am; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jan 30, 2012 6:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
No, it's the debugger that's a big bummer.
User trace rules over debugger like Compute node rules over mapping node.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Mon Jan 30, 2012 6:55 am Post subject: Re: MB8 Mapping Node Staggeringly slow.. |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
I guess there is a full *walk down* to each element? Probably it uses XSLT internally ?
Should the runtime try and otimize... probably no... because it has in general no clue about the message structure and how to properly/effectively navigate within it. With ESQL you (hopefully) provide this information. This is not SQL (where there is an query optimizer) and where you can do what you want (ok, no joins  ) and end up with a fast query.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 30, 2012 6:58 am Post subject: Re: MB8 Mapping Node Staggeringly slow.. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| I guess there is a full *walk down* to each element? Probably it uses XSLT internally ?! |
That's not an issue with the mapping node but an issue with the debugger. Because it produces that helpful little tree with the input message at the top, it needs to parse the entire message to produce that.
This is also why there are so many posts in this forum along the lines of:
"I'm reading an XML document and updating a database. I see 200 updates then the flow fails with a parser error. When I try to debug the flow it fails immediately. Please help me".
The help is of course to run a user trace which has the same (typically on-demand) parsing model.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 30, 2012 7:04 am Post subject: Re: MB8 Mapping Node Staggeringly slow.. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| With ESQL you (hopefully) provide this information. This is not SQL (where there is an query optimizer) and where you can do what you want (ok, no joins ) and end up with a fast query. |
It is possible (though clearly harder) to produce a badly performing mapping within the mapping node as it is within the compute node.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kotagiriaashish |
| Posted: Mon Jan 30, 2012 7:09 am Post subject: |
|
|
Disciple
Joined: 06 Aug 2011
Posts: 165
|
| ya the debugger is indeed a bummer... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jan 30, 2012 7:10 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 30, 2012 7:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kotagiriaashish wrote: |
| ya the debugger is indeed a bummer... |
You should have seen the earlier versions of it.
I (alarmingly) agree with the previous poster. Learn to love trace nodes & user trace. Faster & provides so much more information.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kotagiriaashish |
| Posted: Mon Jan 30, 2012 7:13 am Post subject: |
|
|
Disciple
Joined: 06 Aug 2011
Posts: 165
|
lancelotlinc i indeed agree that trace is a better option but while experimenting putting a trace node then linking a file to it ... is lengthy process... debugging is much easier... |
|
| Back to top |
|
|
| kotagiriaashish |
| Posted: Mon Jan 30, 2012 7:14 am Post subject: |
|
|
Disciple
Joined: 06 Aug 2011
Posts: 165
|
| Vitor wrote: |
| kotagiriaashish wrote: |
| ya the debugger is indeed a bummer... |
You should have seen the earlier versions of it.
I (alarmingly) agree with the previous poster. Learn to love trace nodes & user trace. Faster & provides so much more information. |
I would really love to ... but the user trace is tooo longgggggg |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jan 30, 2012 7:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| kotagiriaashish wrote: |
lancelotlinc i indeed agree that trace is a better option but while experimenting putting a trace node then linking a file to it ... is lengthy process... debugging is much easier... |
Use separate trace files for each unique trace node.
Interactive debugging can be useful. But Trace nodes will serve you where interactive debugging cannot. For example, when using Web Services.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 30, 2012 7:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kotagiriaashish wrote: |
| I would really love to ... but the user trace is tooo longgggggg |
And you have no means of viewing it that has a search facility???? 
Ok, so what's faster? Waiting for the debugger or locating the correct point in the trace? Which gives you more information in return for the time you've spent?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Mon Jan 30, 2012 7:29 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Use a debugger (it works great since they put in Java-Standard-Debugging in Version 6.1) and use the trace node if you require more information.
Or use the trace node (only), if you are used to it from the early Broker-times, when the debugger wasn't that useful (pre 6.0) .
What is under the hood of the mapping node (in Version 8 )?
And... how does the mapping node perform compared to other (Compute) nodes?
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Jan 30, 2012 7:55 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If you try to read a usertrace output with notepad then you will probably be better off with the debugger.
Modern text editors do a better job. I use UltraEdit. Notepad++ is probably just as good.
One thing that a lot of people forget about taking a usertrace is that you can not only find out where the code goes wrong but where the mistake that caused it ws in the first place even if it was several nodes earlier in the flow.
You can't easily do that with the debugger.
The trace output is also good at telling you where you get a path to some data wrong.
But hey, I'm just a grey haired  so what do I know then? 
_________________
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 |
|
|
| kotagiriaashish |
| Posted: Mon Jan 30, 2012 9:15 am Post subject: |
|
|
Disciple
Joined: 06 Aug 2011
Posts: 165
|
I will put all my efforts to get used to trace  |
|
| Back to top |
|
|
|
|
