| Author |
Message
|
| allenm |
 Posted: Mon Feb 05, 2018 8:49 am Post subject: MQ PUT/GET OUTSIDE SYNCPOINT |
 |
|
Newbie
Joined: 08 Jan 2018
Posts: 8
|
Please confirm if my understanding of the following is correct:
Scenario: A distributed application puts a high volume (200-800 per second) of request messages onto ten shared mainframe queues (MQ v8.0) via SVRCONN channels . Each of these non-triggered queues have multiple CICS transactions processing these requests and putting responses onto another set of ten shared queues then read by distributed processes. All the requests are processed by MSGID and all the queues are non-persistent. CICS syncpoints are issued every 200 messages.
Goal: Improve throughput by eliminating as much of the MQ wait time as possible.
Proposal: Have the application issue all puts and gets outside of syncpoint. The messages are non-persistent, the data is stale after a few seconds and the application/business is not concerned for message rollback. My understanding is that putting/getting within syncpoint will lock the message until a commit/syncpoint is issued. By modifying the application to put/get outside of syncpoint this delay will be avoided. Is this correct?
Note that these transactions are long running (with built in delays), therefore all SMF statistics are aggregate so we cannot accurately state the value of MQ wait times.
My question is really is just to ensure that my understanding of the syncpoint process in the above regard is correct.
Thanks. Allen |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 05, 2018 8:56 am Post subject: Re: MQ PUT/GET OUTSIDE SYNCPOINT |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| allenm wrote: |
| Is this correct? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 05, 2018 9:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Index the queue by msgid for faster matching.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Feb 05, 2018 4:10 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
| Index the queue by msgid for faster matching. |
Or by correlid if this is matched on the reply queues.
This will make a big difference if the reply queues reach a significant depth. (>100, YMMV)
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 05, 2018 10:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| allenm wrote: |
| ... ten shared mainframe queues (MQ v8.0) via SVRCONN channels . |
Firstly, I'd say that on a z/OS platform, 200/sec is not high-volume.
For clarity: Is your z/OS Parallel Sysplex? Are these shared mainframe queues in a Coupling Facility?
| allenm wrote: |
| Each of these non-triggered queues have multiple CICS transactions processing these requests and putting responses onto another set of ten shared queues then read by distributed processes. |
How many is multiple? Two, ten? twenty?
| allenm wrote: |
| All the requests are processed by MSGID and all the queues are non-persistent. CICS syncpoints are issued every 200 messages. |
What exactly do you mean by 'All?' Do you mean that producer apps also wait until 200 messages are produced? Or that consumer apps wait until it has consumed 200 messages?
Why does this sound like an exam question?
_________________
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.
Last edited by bruce2359 on Tue Feb 06, 2018 6:30 am; edited 3 times in total |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Feb 06, 2018 12:05 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Consider using Async Put to put the messages
If you are doing get by MsgId and each message is a different MsgId then I would ensure that Read-Ahead is off
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 06, 2018 5:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| allenm |
| Posted: Wed Feb 07, 2018 7:51 am Post subject: |
|
|
Newbie
Joined: 08 Jan 2018
Posts: 8
|
| bruce2359 wrote: |
| allenm wrote: |
| ... ten shared mainframe queues (MQ v8.0) via SVRCONN channels . |
Firstly, I'd say that on a z/OS platform, 200/sec is not high-volume.
For clarity: Is your z/OS Parallel Sysplex? Are these shared mainframe queues in a Coupling Facility?
YES.YES.
| allenm wrote: |
| Each of these non-triggered queues have multiple CICS transactions processing these requests and putting responses onto another set of ten shared queues then read by distributed processes. |
How many is multiple? Two, ten? twenty?
EACH QUEUE IS PROCESSED BY EIGHT TRANSACTIONS PERFORMING IDENTICAL WORK.
| allenm wrote: |
| All the requests are processed by MSGID and all the queues are non-persistent. CICS syncpoints are issued every 200 messages. |
What exactly do you mean by 'All?' Do you mean that producer apps also wait until 200 messages are produced? Or that consumer apps wait until it has consumed 200 messages?
UNCERTAIN ABOUT THIS, NEED TO REVIEW WITH DEVELOPERS.
Why does this sound like an exam question? |
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 07, 2018 11:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Are you a z/OS sysprog? Experience with CF, Parallel Sysplex, WLM? If not, chat with sysprogs, as they are responsible for overall image performance.
Has SMF and RMF data documented performance of the app? Anything unusual?
How many z/OS images are in the Plex sharing this MQ workload? How many CICS regions in the Plex sharing the workload?
_________________
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 |
|
|
| allenm |
| Posted: Wed Feb 07, 2018 11:34 am Post subject: |
|
|
Newbie
Joined: 08 Jan 2018
Posts: 8
|
| bruce2359 wrote: |
Are you a z/OS sysprog? Experience with CF, Parallel Sysplex, WLM? If not, chat with sysprogs, as they are responsible for overall image performance.
YES, I HAVE EXPERIENCE WITH THE ABOVE z/OS COMPONENTS.
Has SMF and RMF data documented performance of the app? Anything unusual?
SMF/RMF PERFORMANCE NUMBERS ACTUALLY LOOK REAL GOOD.
How many z/OS images are in the Plex sharing this MQ workload? How many CICS regions in the Plex sharing the workload? |
TWO IMAGES, FOUR REGIONS.
I AM TRYING TO DETERMINE IF I SHOULD ENCOURAGE THE APPLICATION TO PUT/GET OUTSIDE OF SYNCPOINT AS ALL THE MESSAGES ARE NON-PERSISTENT. MY UNDERSTANDING IS THIS WILL FREE UP THE LOCKING INHERENT IN CODING WITHIN SYNCPOINT. THANKS FOR YOUR RESPONSE. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 07, 2018 12:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| allenm wrote: |
| I AM TRYING TO DETERMINE IF I SHOULD ENCOURAGE THE APPLICATION TO PUT/GET OUTSIDE OF SYNCPOINT AS ALL THE MESSAGES ARE NON-PERSISTENT. MY UNDERSTANDING IS THIS WILL FREE UP THE LOCKING INHERENT IN CODING WITHIN SYNCPOINT. THANKS FOR YOUR RESPONSE. |
You seem to be laser-focused on outside-syncpoint vs. in-syncpoint. Why have you summarily discarded some of the other tuning suggestions found in the two IBM URLs? These will not require any application changes, and should not result in changes in application behavior.
What problem/issue are you seeing? Are your apps missing Service Level Agreements, for example?
Before you encourage an application change, how will you measure the effect of outside-syncpoint vs. in-syncpoint?
You didn't answer my question as to your technical expertise? Are you a z/OS specialist? An MQ specialist?
_________________
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 |
|
|
| bruce2359 |
| Posted: Wed Feb 07, 2018 12:42 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You may realize the benefit of throughput improvement, but what risks have you identified if apps are modified to do gets/puts outside-syncpoint?
Your management should ask you this question. I'd be surprised (shocked) if they didn't.
_________________
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 |
|
|
| allenm |
| Posted: Wed Feb 07, 2018 1:44 pm Post subject: |
|
|
Newbie
Joined: 08 Jan 2018
Posts: 8
|
| bruce2359 wrote: |
You may realize the benefit of throughput improvement, but what risks have you identified if apps are modified to do gets/puts outside-syncpoint?
Your management should ask you this question. I'd be surprised (shocked) if they didn't. |
TRUE. THEY UNDERSTAND THE MESSAGE IS STALE AFTER < 60 SECONDS AND THERE IS NO CONCERN IF LOST OR NON-RECOVERABLE/COMMITTED |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 07, 2018 2:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Did you also read the part where it says that there are some efficiency using syncpoint if you're dealing with persistent messages? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| allenm |
| Posted: Wed Feb 07, 2018 2:11 pm Post subject: |
|
|
Newbie
Joined: 08 Jan 2018
Posts: 8
|
| fjb_saper wrote: |
| Did you also read the part where it says that there are some efficiency using syncpoint if you're dealing with persistent messages? |
YES, AND ALSO THERE ARE EFFICIENCIES USING NON-PERSISTENT MESSAGES OUTSIDE OF SYNCPOINT. MQ IS STREAMLINED FOR PERSISTENT/SYNCPOINT AND NON-PERSISTENT/NO_SYNCPOINT MESSAGES....DON'T ASK WHERE I READ IT BECUASE I DONT' REMEMBER. |
|
| Back to top |
|
|
|
|
