| Author |
Message
|
| jon |
 Posted: Wed Nov 25, 2009 6:50 pm Post subject: Which one is better - Compute nodes or Database Nodes ? |
 |
|
Apprentice
Joined: 17 May 2009
Posts: 32
|
Hi friends,
while desinging a message flow in Websphere Message Broker V6, I have a database operation. I am not sure whethe to use compute node for the same or one of the different Database nodes.
which one is better in terms of performance, I am looking to get a better throughput.
Regards
_________________
When you have a dream, you've got to grab it and never let go. - Carol Burnett |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Thu Nov 26, 2009 5:51 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
There is no such big difference.
but i suggest you to Go ahead with Compute node.
Where you can do data mapping as well you can call DBs too.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Nov 26, 2009 7:24 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Some of the V7 patterns use Database nodes in preference to Compute nodes, with the following reasoning in the description: "Note that database module is used even though no data source is being referenced. This node is used to enhance performance as no part of the message tree has to be copied."
Someone with more knowledge of this area will be able to explain exactly why this is.  |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Nov 26, 2009 8:46 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| Someone with more knowledge of this area will be able to explain exactly why this is |
The actual difference between the Database node and the Compute node is NOT the accessing of databases as both nodes can do this, which does mean their names can be slightly confusing. The actual (and only) difference is that a ComputeNode always creates a new message (even if you never use it), whereas a Database node never creates a new message. You can obviously do more in a Compute node than in a DB node (like create a changed OutputRoot message which you can not do in a DB node). But if all you want to do in the node is access and/or change the Envrionment or LocalEnvrionment trees then you can do this in the Database node which is why the patterns used the DB node where they do as they are simply setting a flag in the LE.
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Nov 26, 2009 8:49 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Nov 26, 2009 9:30 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
| Wow, this patterns stuff is paying off already, even if it is on a v6 system |
|
| Back to top |
|
|
| AkankshA |
| Posted: Fri Nov 27, 2009 12:32 am Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
| mgk wrote: |
| Quote: |
| Someone with more knowledge of this area will be able to explain exactly why this is |
The actual difference between the Database node and the Compute node is NOT the accessing of databases as both nodes can do this, which does mean their names can be slightly confusing. The actual (and only) difference is that a ComputeNode always creates a new message (even if you never use it), whereas a Database node never creates a new message. You can obviously do more in a Compute node than in a DB node (like create a changed OutputRoot message which you can not do in a DB node). But if all you want to do in the node is access and/or change the Envrionment or LocalEnvrionment trees then you can do this in the Database node which is why the patterns used the DB node where they do as they are simply setting a flag in the LE.
Kind Regards, |
so going by this... in a way when i can use both filter and compute nodes.... my filter node will also be better performant then compute node... am i correct ?
_________________
Cheers |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Fri Nov 27, 2009 12:34 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
then there will be one more question
How many nodes you will keep in your flow?
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Nov 27, 2009 12:56 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Gaya3 wrote: |
then there will be one more question
How many nodes you will keep in your flow? |
What's your point?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Fri Nov 27, 2009 1:08 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| Michael Dag wrote: |
| Gaya3 wrote: |
then there will be one more question
How many nodes you will keep in your flow? |
What's your point? |
Minimize the number of nodes. 
Input -->Compute -->Ouput + error Handling Subflow [One way of designing] - Max it comes to 5 nodes here
Where i usually go for JCN. it depends again for others. 
Transactions increases if you add more nodes in your flow.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Nov 27, 2009 1:22 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Gaya3 wrote: |
| Michael Dag wrote: |
| Gaya3 wrote: |
then there will be one more question
How many nodes you will keep in your flow? |
What's your point? |
Minimize the number of nodes.
Input -->Compute -->Ouput + error Handling Subflow [One way of designing] - Max it comes to 5 nodes here
Where i usually go for JCN. it depends again for others.
Transactions increases if you add more nodes in your flow. |
There is always the trade-off between the minimalistic design you propose (the way I read it you put everything in one compute node...)
and maintainability/readability...
If I were to maintain these flows I would rather see for example:
Input -->filter node -->Compute(s) -->Database(s)--->Ouput
rather then one big bowl of spagetti... in one node...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Nov 27, 2009 1:50 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| AkankshA wrote: |
so going by this... in a way when i can use both filter and compute nodes.... my filter node will also be better performant then compute node... am i correct ? |
That has always been my understanding.
A quick question for mgk though.... Does the compute node always create a new message even if you tell it that you only wish to work on one of the available trees (eg Exception List)? I've used this setting before (when I did not need to manipulate the message) and the memory requirements of the flow was noticably different (there were a few compute nodes in the flow to make this a worthwhile activity). With this in mind I normally opt for using compute nodes (with the settings as previously described) over the DB node for accessing DBs because it offers more flexibility going forwards (ie if message manipulation / complex queries become a requirement). |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Nov 27, 2009 3:13 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
OK, quite a few issues raised here
| Quote: |
| Does the compute node always create a new messag |
Yes, because you could use an EVAL statement to generate code that accesses an Output* tree. Also, if you look at the Compute nodes ComputeMode property you will notice that there is currently no option to propagate ALL the Input* trees - you have to choose at least one of the Output* ones even if you leave that output tree empty and never access it in the node.
| Quote: |
| ...even if you tell it that you only wish to work on one of the available trees (eg Exception List)? |
Don't forget what when/if your ComputeMode says "ExceptionList" that is refering the the NEW (OutputExceptionList) and not the InputExceptionList...
Regarding the Filter node, in this case there are a few extra differences between it and the DB and Compute node. Like the DB node, it never creates a new message, but on the other hand you cannot use the PROPAGATE statement in a Filter node (it ignores it if you try - see the docs) and has difference output terminals etc.
I should point out that cost of the extra message creation is very tiny, and should not really be used as a big factor when deciding which node to use. The actual decision should come down to the work the node needs to do: If you only want to look at a field or update the LE or Envrionment trees then you can use a DB node. If you need to work with an Output message then use a Compute node. This simply comes down to needing to work with one message (input) or two (input and output).
I hope this clarifies things somewhat...
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 27, 2009 4:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It seems to me that if we are going to encourage this 'off-label' use of the Database node, that perhaps we should adjust the label.
Not, mind you, that I have a good suggestion for a new name for the Database node. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Nov 27, 2009 5:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
Not, mind you, that I have a good suggestion for a new name for the Database node. |
How about Depreciated? 
(only joking)
_________________
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 |
|
|
|
|
