| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ performance |
« View previous topic :: View next topic » |
| Author |
Message
|
| gbaddeley |
 Posted: Wed Mar 09, 2011 2:09 pm Post subject: Re: Required Functions |
 |
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| edwarm4 wrote: |
| MB txn ---> DB2 SP ---> MQCONN ---> MQOPEN ---> MQGET using search criteria and wait time of 2 seconds ---> MQCLOSE ---> MQDISCONNECT ---> DB2 SP ---> MB txn |
MQCONN and MQOPEN are quite expensive calls to MQ, of the order of a few milliseconds each. It's unlikely you will achieve your performance target.
High performance consumer programs are long running. They will MQCONN and MQOPEN once, and then loop on MQGET with an infinite Wait.
_________________
Glenn |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Mar 09, 2011 2:28 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...of the order of a few milliseconds each |
May have been true a decade ago, or currently on UNIX/Windoze hardware.
If the pathlength (number of instructions) to mqconnect remained constant, and mqconnect took a few milliseconds 10 years ago; BUT the MIPS rate doubled, then doubled, then doubled, I'd expect to see a few hundred nano-seconds or microseconds for an mqconnect.
Someone with a zBox, and time-to-spare: please turn on MQ and GTF trace, start an app, observe and report the time from mqconnect call to CC/RC returned after the call.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 10, 2011 12:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You don't have to use an indefinite get wait, using an interval of say 60 seconds and then checking for an application closedown request (not the same as quiescing the QM), before repeating the GET wait is one approach that works well.
If message arrival is bursty then closing the queue after a get wait of 60 secs (with no message) is also efficient because it will keep the queue open when message arrival is frequent but let it close when there is nothing much going on. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Mar 10, 2011 2:30 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
| You don't have to use an indefinite get wait, using an interval of say 60 seconds and then checking for an application closedown request (not the same as quiescing the QM), before repeating the GET wait is one approach that works well. |
Another approach is to use the async consume feature introduced in MQ v7.0.0. The main thread of the app can idle on waiting for an app close down request *and* waiting for an MQ message to arrive.
| Quote: |
| If message arrival is bursty then closing the queue after a get wait of 60 secs (with no message) is also efficient because it will keep the queue open when message arrival is frequent but let it close when there is nothing much going on. |
I might consider this design if the app was processing lots of different queues, or there were lots of instances of it, but if its only using one or two queues, I'd just leave the queues open indefinitely. There is no efficiency penalty in doing so, other than using a bit more memory in MQ.
_________________
Glenn |
|
| 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
|
|
|
|
