| Author |
Message
|
| messg_wb |
 Posted: Wed Feb 18, 2009 12:53 pm Post subject: Message flow is slow (on mainframe) |
 |
|
Acolyte
Joined: 29 Sep 2005
Posts: 51
|
Hi - We have message flow (broker/database's on mainframe) that does message processing (db2 database queries) in esql that takes as much as 6 secs, which seems very low. We checked the database queries and time taken by them is less than sec. Not sure, where the bottleneck is !! Any ideas ?
Thanks |
|
| Back to top |
|
 |
| kimbert |
| Posted: Wed Feb 18, 2009 1:51 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Without a lot more info, it's going to be tricky. My usual approach is to start removing stuff to see whether things start to go faster...
Sorry if that doesn't sound like rocket science  |
|
| Back to top |
|
|
| messg_wb |
| Posted: Thu Feb 19, 2009 6:04 am Post subject: |
|
|
Acolyte
Joined: 29 Sep 2005
Posts: 51
|
Thanks Kimbert. I tried that but did not help much. I added 5 more instances but did not see improovement either
I wonder, If there are any configurable parameters in odbc (communication between broker and broker database), that could speed up things.
Thanks |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Feb 19, 2009 6:47 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
we once had an issue with a slow flow, and it turned out that there was not enough storage available... we had to change _CEE_RUNOPTS (we run on z/OS) and had to increase the threadstack memory.
i am not an expert in this area, but maybe you should have a look at the memory too....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| messg_wb |
| Posted: Thu Feb 19, 2009 1:59 pm Post subject: |
|
|
Acolyte
Joined: 29 Sep 2005
Posts: 51
|
Thanks Butcher for your input, It seems like a possibility. They checked the variable and it is '_CEE_RUNOPTS=STORAGE(NONE,NONE,NONE,00)', Can you suggest any value for it, still waiting to hear from mainframe admins aswell
We tested same message flow (broker/database) on AIX and performance is doubled i.e. 8-10 msgs/sec.
Appreciate your valuable input. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Feb 19, 2009 9:07 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
as i already said i am not an expert in this area, here is what we use (what we were recommended to use by IBM support)
_CEE_RUNOPTS=XPLINK(ON),RPTSTG(ON),THREADSTACK(ON,,,ANY,KEEP,4M,128K)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| messg_wb |
| Posted: Fri Feb 20, 2009 1:46 pm Post subject: |
|
|
Acolyte
Joined: 29 Sep 2005
Posts: 51
|
Thanks Mr.Butcher
Its resolved, removed the message set and parsed input msg as blob and manually parsed in the esql code and thruput in increased by 10 times. I am surprised !! |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Feb 20, 2009 1:55 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| removed the message set and parsed input msg as blob and manually parsed in the esql code |
I would very much like to know
a) why you did not immediately track the problem down to the parsing. Surely, if you had simply reduced the flow to a simple input/output node with parse timing set to 'Immediate' you would have found the bottleneck straight away?
b) what style of input message you are using, and how your message set was designed.
c) which version of message broker you are using |
|
| Back to top |
|
|
| messg_wb |
| Posted: Sun Feb 22, 2009 6:29 am Post subject: |
|
|
Acolyte
Joined: 29 Sep 2005
Posts: 51
|
Kimbert - Apologies for responding so late, as below
a) why you did not immediately track the problem down to the parsing. Surely, if you had simply reduced the flow to a simple input/output node with parse timing set to 'Immediate' you would have found the bottleneck straight away?
Very True, should have resolved as parsing issue, lot earlier. We were looking more from server perspective as through put on AIX server (1CPU/4GB RAM) was double than on mainframe. Also, I did not get to design msg flow/set, I was just involved in improoving perf so that made me overlook that ** important ** aspect, no excuses, it was bad troubleshooting
b) what style of input message you are using, and how your message set was designed.
It was designed as MRM msg (variable length tag delimited), Ofcourse, now its blob. Certain part of msg only was used for database updates so I guess, it was less resource intensive (trade off between through put and CPU consumption) to have custom parser (in esql) than in-built one
c) which version of message broker you are using
6.0.1
Thanks |
|
| Back to top |
|
|
|
|
