| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Request Reply Model |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu Oct 27, 2011 6:07 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
It does; but it only illustrates one metric.
SMF dutifully reported on time-in-processor, and suspends-from-processor for a given application. Neither of these metrics reflect how badly MVS manages workload; rather, they reflect how efficiently and effectively MVS manages aggregate workload through the system.
A manager I worked for years ago got target-locked on high paging rates. (During peak load, MVS was paging at 6,000/pps.) When he asked me what I intended to do about it, I asked him if we were missing any SLAs; or even getting close to missing SLAs. Yes, SMF and RMF dutifully reported these events.
One of my WMQ clients (people, not apps) lamented about performance of his Windows app running sluggishly. The app was written with MQPUT1 calls, since the original spec called for very infrequent message puts. When app use increased, their choice of MQPUT1 no longer made business sense.
MVS moves massive amounts of data concurrently. MVS manages dozens of concurrent processors.
I will agree that ... if you are missing SLAs, and have run out of tuning knobs on z/OS, and you can demonstrate that changing apps to use fixed RTQs will improve (or not adversely degrade) aggregate throughput, then make that choice.
History has shown that we should not develop applications around hardware and software architecture, as these change frequently.
_________________
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: Thu Oct 27, 2011 6:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| History has shown that we should not develop applications around hardware and software architecture, as these change frequently. |
Yes.
This is exactly why you shouldn't use TDQs. Because you should design applications around the expected usecase of the application. And that usecase almost certainly DOES NOT FIT the usecase for TDQs, or if it does currently it likely won't in the future.
It's like your MQPUT1 example. The app was designed for a specific usecase that allowed for the use of MQPUT1s. And then the usecase drifted... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 6:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
If the answer to the question "why did you pick dynamic vs. static TDQs?" is "because on z/OS WMQ does or doesn't use n-microseconds or n-nanoseconds to do this or that," then the choice is today's platform-dependent. If in v8, the internal architecture changes (improves), the choice may no longer be the right one.
So, is the OP missing SLAs? Will the micro-seconds today or nano-seconds tomorrow yield enough benefit? Will perf-tuning WMQ in this application fashion improve, degrade, or have little impact on aggregate throughput? These are the questions I ask developers/architects when they get target-locked on minutia like this.
_________________
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: Thu Oct 27, 2011 6:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| If the answer to the question "why did you pick dynamic vs. static TDQs?" is "because on z/OS WMQ does or doesn't use n-microseconds or n-nanoseconds to do this or that," |
You continue to refuse my point.
My point is that you should not use TDQs in any form - static or dynamic.
So the question is NOT "why did you pick dynamic versus static TDQs". It's "Why did you pick TDQs instead of a static real queue"?
And the answer to that question is NOT Platform/technology dependent. And there's likely not a GOOD answer. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 8:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| bruce2359 wrote: |
| If the answer to the question "why did you pick dynamic vs. static TDQs?" is "because on z/OS WMQ does or doesn't use n-microseconds or n-nanoseconds to do this or that," |
Oooops. I miss-typed. Sorry.
Why pick static (pre-defined) vs. dynamic queues?
The presumption in the answer is that there will be more/less work for the processor(s) in creating dynamic RTQs vs. multiple matches against a pre-defined local queue.
Earlier, I suggested a scenario where an app comes to life, creates a dynamic RTQ, issues a request message; then waits for the replies. Only replies for that request will arrive. No matching is required. There is some labor required to create RTQs; but no matching is necessary.
For a static RTQ, a queue used by many instances of a variety of apps, each must match. This was the scenario I intended.
My scenario was based on a client that had one, and only one, all-purpose, generic reply-to-queue, that all apps used. Not my design; but a design based on the ROT (rule of thumb) 'don't use dynamic RTQs on z/OS.' I'm skeptical of always/never statements. The client experienced widely varied response-times, as few, dozens or hundreds of concurrent apps matched using this single RTQ.
_________________
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: Thu Oct 27, 2011 8:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Why pick static (pre-defined) vs. dynamic queues? |
Yes. Don't use dynamic queues.
| bruce2359 wrote: |
| For a static RTQ, a queue used by many instances of a variety of apps, each must match. This was the scenario I intended. |
Each app should have it's own queues.
| bruce2359 wrote: |
| My scenario was based on a client that had one, and only one, all-purpose, generic reply-to-queue, that all apps used. Not my design; but a design based on the ROT (rule of thumb) 'don't use dynamic RTQs on z/OS.' The client experienced widely varied response-times, as few, dozens or hundreds of concurrent apps matched using this single RTQ. |
Well. They've taken a good idea - "don't use dynamic queues" and then run it so far underground that they've hit up against "don't use deep queues" and/or "don't share queues between apps".
| bruce2359 wrote: |
| I'm skeptical of always/never statements. |
I always interpret "always/never" statements as "make sure you know what you're doing before trying anything different", and I never fail to read the documentation thoroughly before attempting anything else. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 8:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
The very first tool I learned how to use was a hammer. I used it for all kinds of things, including things for which a screwdriver or wrench would have been more appropriate.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Oct 27, 2011 10:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
One of the benefits of predefined reply queues over dynamic queues is that you can set up alerting and monitoring for a predefined local queue, and if you have the right MQ management tools in house (i.e. QPASA), you can look at historical data on things like q depths and throughput rates.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| elkinsc |
| Posted: Thu Oct 27, 2011 12:59 pm Post subject: I agree, monitoring is really important |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
That is an excellent point on monitoring the reply queues.
TDQs are awfully convenient for applications, and you don't have to worry about pesky things like proper indexing or abandoned messages. But like anything convenient there are hidden costs that must be paid. Like the gas at a drive thru. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 27, 2011 3:02 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Just to weigh in, many years ago a 'sage' told me that if you need TDQs, or 'worse' PDQs, either you'd got the solution design wrong, or you weren't using MS03. I acknowledge this doesn't bring much to the argument, but I've never had a reason to use them, every standards doc I've seen at the sites I've been at have stated they're not to be used (but that's probably because they never had a viable use-case), so I've always shied away from them myself. Is there any one out there that has a definitive and absolute case of why they should be used?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 4:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| exerk wrote: |
| ...many years ago ... |
I believe this is/was one of those ROTs (rules of thumb) that reflected more the state of dynamic queues back at v2 era. Way back at v4.1, an MVS mq support team person I was working with mentioned the n-number of machine instructions (path length) it took to create a dynamic queue. The ROT was for a particular version/release. Does it apply with current WMQ releases?
Somewhere in the v5/v6 era, another support person mentioned that, to improve throughput, qmgr software maintained/maintains a pool of pre-built, skeleton queues, so that the instruction path length is dramatically shorter for dynamic queues. The ROT of-old became an iROT (irrational rule of thumb); but iRots tend have a lives of their own.
Perhaps someone from the support team can shed some light on this... or not.
This minutia is not something I lose sleep over; but being a propeller-head, I try to keep. I'm concerned more with aggregate workload throughput; and look to a wide variety of tuning opportunities to meet SLAs.
_________________
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 |
|
|
| elkinsc |
| Posted: Thu Oct 27, 2011 4:44 pm Post subject: The performance improvements for TDQs |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
as supplied by the 'skeleton queues' enhancement, was only applied to the distributed version of MQ, not on z/OS. I was just not specific enough in my earlier posting. Those changes have never been ported to z/OS. Perhaps someone from this community would submit a requirement for this? If it comes from a customer it gets far more weight than from me.
As a geek, the CPU requirements for TDQs I've seen have ranged from as much as 1500 microseconds to the low of 200 more than the same requests to private queues.
Have a lovely evening all! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 28, 2011 10:42 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| exerk wrote: |
| Just to weigh in, many years ago a 'sage' told me that if you need TDQs, or 'worse' PDQs, either you'd got the solution design wrong, or you weren't using MS03.... Is there any one out there that has a definitive and absolute case of why they should be used? |
Yes ... and the use of TDQ is mandated by a bad application design of the requesting application... 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
