ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexMainframe, CICS, TXSeriesMQ PUT/GET OUTSIDE SYNCPOINT

Post new topicReply to topic Goto page 1, 2  Next
MQ PUT/GET OUTSIDE SYNCPOINT View previous topic :: View next topic
Author Message
allenm
PostPosted: Mon Feb 05, 2018 8:49 am Post subject: MQ PUT/GET OUTSIDE SYNCPOINT Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

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
View user's profile Send private message
Vitor
PostPosted: Mon Feb 05, 2018 8:56 am Post subject: Re: MQ PUT/GET OUTSIDE SYNCPOINT Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25068
Location: Ohio, USA

allenm wrote:
Is this correct?




_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Feb 05, 2018 9:46 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5646
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
View user's profile Send private message
gbaddeley
PostPosted: Mon Feb 05, 2018 4:10 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1833
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
View user's profile Send private message
bruce2359
PostPosted: Mon Feb 05, 2018 10:00 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8078
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 would tell you a UDP joke, but you might not get it.


Last edited by bruce2359 on Tue Feb 06, 2018 6:30 am; edited 3 times in total
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Tue Feb 06, 2018 12:05 am Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 902
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
View user's profile Send private message Visit poster's website
PeterPotkay
PostPosted: Tue Feb 06, 2018 5:18 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7435

What do I need to consider for MQ on z/OS performance
https://www.ibm.com/developerworks/community/blogs/c4142f9d-6cf1-44ef-a44a-b09428ad96d1/entry/what_do_i_need_to_consider_for_mq_on_z_os_perfomance?lang=en

Tips for MQ performance on z/OS
https://www.ibm.com/developerworks/community/blogs/c4142f9d-6cf1-44ef-a44a-b09428ad96d1/entry/tips_for_mq_performance_on_z_os?lang=en
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
allenm
PostPosted: Wed Feb 07, 2018 7:51 am Post subject: Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

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
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 11:22 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8078
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
allenm
PostPosted: Wed Feb 07, 2018 11:34 am Post subject: Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

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
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 12:01 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8078
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 12:42 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8078
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
allenm
PostPosted: Wed Feb 07, 2018 1:44 pm Post subject: Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Feb 07, 2018 2:01 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19705
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
View user's profile Send private message Send e-mail
allenm
PostPosted: Wed Feb 07, 2018 2:11 pm Post subject: Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexMainframe, CICS, TXSeriesMQ PUT/GET OUTSIDE SYNCPOINT
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.