| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQOPEN performance on Z/OS... |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Wed Feb 25, 2009 11:07 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If you open the same queue again, you get a new open handle.
You should try to re-use the handle (by not opening it again), but it's possible a subsequent open might be faster, it depends how the MQ system code is written.
The design needs to be such that MQCONN and MQOPEN are not repeatedly issued. This is especially true for a MQ client application against an "expensive" platform like z/OS.
There comes a point when a design is simply not acceptable. Re-using open handles is not exactly rocket science. |
|
| Back to top |
|
 |
| Maximus |
| Posted: Wed Feb 25, 2009 11:36 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| zpat wrote: |
If you open the same queue again, you get a new open handle.
You should try to re-use the handle (by not opening it again), but it's possible a subsequent open might be faster, it depends how the MQ system code is written.
The design needs to be such that MQCONN and MQOPEN are not repeatedly issued. This is especially true for a MQ client application against an "expensive" platform like z/OS.
There comes a point when a design is simply not acceptable. Re-using open handles is not exactly rocket science. |
Reusing MQCONN is easy because the connection pool does just that. But reusing the MQOPEN handle is another story and you need to write your own code for that. Correct?
In JMS, in a request/response pattern where there are many different request queues, the easy way is to open/put/close the request queue and then open/get wait/close the response queue. What could be a good design to avoid having to re-open the same queue over and over? Is it something you need to code or already exist? |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 25, 2009 11:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't understand the "write your own code" comment.
You just need to write the application according to best practice. Invoking an application for a single message is wrong in many cases, esp high volume client applications.
Develop an adapter that connects to MQ, opens the request queue and processes requests (MQGET with WAIT), sends reply (MQPUT) and LOOPs back to the get, until the adapter needs to close down. Then it closes the queues and disconnects.
Long-running listeners/adapters (you can run it several times at once for parallelism if needed) is the way to go. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Feb 25, 2009 10:57 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
MP16.pdf (Capacity Planning and Tuning for WebSphere MQ for z/OS) is suggesting:
CHIADAPS( 30 )
CHIDISPS( 20 )
what do you suggest? We have non-persistent messages that are under 100KB. |
don't have a suggestion at hand. why don't you try the recommended values if there is any change for the better? (think you need to restart qmgr after change)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Maximus |
| Posted: Thu Feb 26, 2009 5:25 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2004
Posts: 57
|
| Mr Butcher wrote: |
| Quote: |
MP16.pdf (Capacity Planning and Tuning for WebSphere MQ for z/OS) is suggesting:
CHIADAPS( 30 )
CHIDISPS( 20 )
what do you suggest? We have non-persistent messages that are under 100KB. |
don't have a suggestion at hand. why don't you try the recommended values if there is any change for the better? (think you need to restart qmgr after change) |
After doing the following changes CHIADAPS( 30 ) and CHIDISPS( 20 ) the performance where greatly improved. MQ is now performing as expected  More tests will be done to see why the CICS transactions don't have the expected response time.
Thanks for everyone help. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
