| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Are SHARED CONSTANTS a performance issue in ESQL? |
« View previous topic :: View next topic » |
| Author |
Message
|
| McueMart |
 Posted: Wed Dec 17, 2014 2:08 am Post subject: Are SHARED CONSTANTS a performance issue in ESQL? |
 |
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Hi all,
This question is aimed at the dev team really (unless any of you others know the Broker internals well!).
In my infinite wisdom, I though that declaring all ESQL CONSTANTS as SHARED would be a good idea. My reasoning was similar to why you often define 'static final' variables in Java - in as much as each thread/object would use the same variable and save memory.
After testing some performance critical flows (which run with many additional instances set), we found that using SHARED CONSTANTs was causing large performance issues (and removing the SHARED keyword fixed it). Could anyone confirm if *reading* a SHARED CONSTANT is done within some kind of atomic mutex (thus causing performance issues when done in multithreaded way)?
Many thanks. |
|
| Back to top |
|
 |
| McueMart |
| Posted: Tue Dec 23, 2014 7:54 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Any of the dev team brave enough to delve into the innards of the code to give me some closure on this issue  ? |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Dec 23, 2014 10:37 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1638
|
I'll have a go . To avoid corruption, SHARED scalar variables are automatically 'read from' and 'written to' under a read/write lock. So yes, it is better to only use SHARED when you really need to share the data between instances of a flow. And even then, copying the shared state into a local variable can help if you need to refer to it multiple times within a node, depending on factors such as throughput, instances datatype of the data etc.
I hope this gives you the closure you seek! 
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 |
|
|
| smdavies99 |
| Posted: Tue Dec 23, 2014 11:57 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The guidance offered by MGK fits in with my observations.
I started using them around V6.0.0.3 (or when they were first introduced)
My flows hold config data in a shared Row. This is read once when the flow starts.
Every time the flow processes a message, the row data is copied into an Environment variable. Therefore the shared variable is only accessed once per operation.
Holding the data in a Row means that there is only one shared variable instead of many.
Compared with reading the config data from a DB table the use of shared variables is in performance terms a no-brainer. It is highly performant.
If you go overboard with the sheer numbers then there might be a performance hit. Good testing will show the best way to store the shared data.
_________________
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 |
|
|
| McueMart |
| Posted: Tue Dec 23, 2014 7:05 pm Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Many thanks mgk! I can now sleep soundly at night  |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
