| Author |
Message
|
| mchan |
 Posted: Wed Oct 26, 2011 12:42 am Post subject: Request Reply Model |
 |
|
Apprentice
Joined: 09 Sep 2011
Posts: 29
|
Are there any general guideline in choosing among the following options for request reply model where multiple requestor using a common server services? Focus may be the performance and ease of maintenance....
Option1: use correlation ID with selector to select the appropriate reply from fixed, shared reply queue
Option2: use temporary reply queue so that reply can be obtain exclusively
Thanks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Oct 26, 2011 1:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| TDQs are not terribly performant. They should only be used in situations where the requester is not going to be running very often. |
|
| Back to top |
|
|
| mchan |
| Posted: Wed Oct 26, 2011 1:35 am Post subject: |
|
|
Apprentice
Joined: 09 Sep 2011
Posts: 29
|
so, use correlation ID with selector to select the appropriate reply from fixed, shared reply queue is much preferred for performance consideration?  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2011 4:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| TDQs are not terribly performant. They should only be used in situations where the requester is not going to be running very often. |
Care to offer an explanation as to why a dynamically created RTQ is not preferred? Or why a admin-defined RTQ is preferred?
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Oct 26, 2011 4:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| mqjeff wrote: |
| TDQs are not terribly performant. They should only be used in situations where the requester is not going to be running very often. |
Care to offer an explanation as to why a dynamically created RTQ is not preferred? Or why a admin-defined RTQ is preferred? |
Particularly on zOS, TDQs are very resource intensive. DO NOT USE TDQs on zed.
Otherwise, for a long running application, why does it need to go to the trouble to create a queue each time it starts up? For a known application with a fixed set of install locations, why does it need to have a dynamically built reply queue?
TDQs are fine for things like saveqmgr, that need to run infrequently with a minimal impact on the qmgr they are connecting to and zero "install" footprint.
Most normal business applications don't fit that usecase. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2011 5:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If memory serves, a v6 or v7 qmgr maintains a pre-built pool of TDQs to be used and reused, as needed.
I don't recall there being an issue with WMQ for z/OS and TDQ's.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Oct 26, 2011 5:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
If memory serves, a v6 or v7 qmgr maintains a pre-built pool of TDQs to be used and reused, as needed.
I don't recall there being an issue with WMQ for z/OS and TDQ's. |
zOS is not my platform of choice. I am repeating things from other people. But I am repeating them from people who are paid to make sure that what they say is correct.
TDQs are CPU and resource intensive on zOS where both CPU and resource usage is expensive.
And, again. The business pattern and use cases that apply to almost all actual business applications built on MQ DOES NOT FIT the usecase for TDQs. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 26, 2011 5:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| TDQs are CPU and resource intensive on zOS where both CPU and resource usage is expensive. |
It's not something I've experienced. But that could be because:
| mqjeff wrote: |
| The business pattern and use cases that apply to almost all actual business applications built on MQ DOES NOT FIT the usecase for TDQs. |
Remember that z/OS has the unique ability to index queues by id so get by id is fast & efficient.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2011 5:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
Particularly on zOS, TDQs are very resource intensive. DO NOT USE TDQs on zed.
TDQs are CPU and resource intensive on zOS where both CPU and resource usage is expensive. |
This is odd, since z platforms have lots of available horsepower, and overall lower cost-per-whatever at transaction rates you would expect to find launched on z/OS. I would have expected your caution to be aimed at midrange platform users about their limited resources.
I do recognize that for each app instantiation, another TDQ would be created. But there will be a resource trade-off between multiple server apps using a shared, single-purpose, pre-defined reply-to-queue, matching on CorrelIds, vs. multiple apps, each using a unique TDQs for a non-matched MQGETs.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Oct 26, 2011 5:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| But there will be a resource trade-off between multiple server apps using a shared, single-purpose, pre-defined reply-to-queue, matching on CorrelIds, vs. multiple apps, each using a unique TDQs for a non-matched MQGETs. |
Why would you be doing non-matched gets in a request/reply pattern?
That's what matching is FOR, to *correlate* the Request and the Reply. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2011 6:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If the requesting app came to life to do one request, then any/all replies to the dynamic RTQ would be for the single request. No need to match.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Oct 26, 2011 6:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| If the requesting app came to life to do one request, then any/all replies to the dynamic RTQ would be for the single request. No need to match. |
Okay. Yes. If, *somehow*, we are talking about an existing app that has it's only job to come alive ONCE and INFREQUENTLY (like saveqmgr), then TDQs do indeed fit the usecase of the app.
But most applications do not exist to come alive ONCE and INFREQUENTLY. Most applications come alive and stay alive for a while.
Even in the case of web-applications where an application might be issuing a single request for a single session, the application is going to be alive for the life of the server container and issuing multiple requests for multiple sessions.
Even in the case of end-user applications, the application is going to be alive for the lifetime of the session with the end user, and likely issuing multiple requests during that session. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2011 8:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Agreed. For an app that makes multiple requests, there will be a need to have the app match on CorrelId to match the outbound request to the reply (or replies).
So, the follow-on question: does matching on a dynamic RTQ associated with a single instance of the requesting app (meaning few reply messages) require more or less resources than multiple apps matching on a single, pre-defined RTQ - with an unknown (none, few, many, thousands) number of messages?
_________________
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 |
|
|
| gbaddeley |
| Posted: Wed Oct 26, 2011 4:50 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
Agreed. For an app that makes multiple requests, there will be a need to have the app match on CorrelId to match the outbound request to the reply (or replies).
So, the follow-on question: does matching on a dynamic RTQ associated with a single instance of the requesting app (meaning few reply messages) require more or less resources than multiple apps matching on a single, pre-defined RTQ - with an unknown (none, few, many, thousands) number of messages? |
Agreed 2. For best performance, use match on CorrelId without any other selectors. If the RTQ depth regularly exceeds a few messages (10? 100? 1000? YMMV), it might be better to break the replies out into several queues, or use dynamic queues.
Use message Expiry on non-critical replies (eg. result of inquiry transaction).
Permanent DQ can be a PITA for support and administration as if there are app problems (or badly coded apps) there may be a build up in numbers and action will need to be taken to clean them up. I have seen 50,000+ DQ on a queue manager after a few months of creep 
_________________
Glenn |
|
| Back to top |
|
|
| elkinsc |
| Posted: Thu Oct 27, 2011 4:38 am Post subject: TDQs on zOS |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
Hi folks,
Back many releases ago (was it 5.something?...I cannot remember) on the distributed platforms TDQs were enhanced for performance. Those same enhancements have not been made to z/OS. There are probably very good reasons for that, below the bar storage consumption would be impacted without a doubt. Above the bar storage was not available that long ago.
So in looking at SMF 116 type 3 data, I typically find that the open and close of a TDQ take at least 200 microseconds of CPU more than the same requests against a permanent queue (that is the low end - I've seen much worse). In addition, the number of suspensions of the request can be significant, in the example I have in front of me the elapsed time for the open was 1441 microseconds and the suspension count was 1301.
Now the CPU usage is may not mean much if you only do that once a day. However, what we see in practice, is that it often takes more CPU than the 200 micros I quoted and the frequency of the requests is so rarely once or twice a day that is builds up into a problem.
Hope this helps!
Lyn |
|
| Back to top |
|
|
|
|
