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 Previous  1, 2
MQ PUT/GET OUTSIDE SYNCPOINT View previous topic :: View next topic
Author Message
bruce2359
PostPosted: Wed Feb 07, 2018 2:23 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8210
Location: US: west coast, almost. Otherwise, enroute.

Again, what is the business benefit to what you propose? Please be precise, and not just 'efficiencies.' What and how will you measure whether you will reach those efficiencies? Improved by n milliseconds per transaction? Increase in n transactions/second?

If transactions stale after n seconds, do apps specify an expiry value in the MQMD? What action does the app take if a msg stales out? How do stale messages support your recommendation to go no-syncpoint?

Please don't capitalize, unless you are referring to an MQ features,functions commands, such as MQPUT, MQMD.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data


Last edited by bruce2359 on Wed Feb 07, 2018 2:33 pm; edited 1 time in total
Back to top
View user's profile Send private message
allenm
PostPosted: Wed Feb 07, 2018 2:31 pm Post subject: Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

bruce2359 wrote:
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.
YES I AM FOR THE MOMENT FOCUSING ON IN/OUT SYNCPOINT AND BY NO MEANS DISCRADED THE OTHER TUNING SUGGESTIONS IN PARTICULAR THE SIZING OF BUFFERS, PSETS, CF STRUCTURE AND SMDS.

What problem/issue are you seeing? Are your apps missing Service Level Agreements, for example?
THE APP HAS AN SLA TO PROCESS 800 MESSAGES PER SECOND (ideal), WE ARE AT 500+ WHICH IS ACCEPTABLE AT THIS POINT.

Before you encourage an application change, how will you measure the effect of outside-syncpoint vs. in-syncpoint?
IF YOU HAVE A SUGGESTION PLEASE LET ME KNOW. WE HAVE A QA ENVIRONMENT WHERE THE CHANGE CAN BE MADE AND MEASURED.

You didn't answer my question as to your technical expertise? Are you a z/OS specialist? An MQ specialist?

I GUESS "CICS/MQ SYSTEMS PROGRAMMER" WOULD BE AN ACCURATE LABEL.
Back to top
View user's profile Send private message
allenm
PostPosted: Wed Feb 07, 2018 2:42 pm Post subject: Reply with quote

Newbie

Joined: 08 Jan 2018
Posts: 7

bruce2359 wrote:
Again, what is the business benefit to what you propose? Please be precise, and not just 'efficiencies.' What and how will you measure whether you will reach those efficiencies? Improved by n milliseconds per transaction? Increase in n transactions/second?

If transactions stale after n seconds, do apps specify an expiry value in the MQMD? What action does the app take if a msg stales out? How do stale messages support your recommendation to go no-syncpoint?
The app does code an expiry value (don't know it) and takes no action if stale. I view a stale message as a message that has no business consequence if it's committed or backed out.

Please don't capitalize, unless you are referring to an MQ features,functions commands, such as MQPUT, MQMD.

Apologies about the caps.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Wed Feb 07, 2018 2:43 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1907
Location: Melbourne, Australia

MQ Syncpoint VS No Syncpoint, and Persistent VS Non Persisent, are design choices that should be made to meet application requirements for quality of service, transaction integrity, recoverability, performance. etc.

A sys prog can analyse performance and bottlenecks, but should not be tweaking these choices without sign off from the application designers.

There are many other performance resources that can be tweaked that do not affect requirements for syncpoint and persistence, such as MQ buffer pools. You should consult with the z/OS sys progs and z/OS performance specialists.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 2:51 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8210
Location: US: west coast, almost. Otherwise, enroute.

STOP CAPITALIZING EVERYTHING.

Tuning efforts need to have a precise definition as to exactly how and what will be changed, a precise definition what outcomes are expected, and how these outcomes will be measured.

Tuning efforts, whether they be at the application level, sub-system level or o/s level require metrics of current behavior BEFORE and AFTER a change.

I gather from your reply that you do not know how to capture and analyze performance data from MQ and z/OS. Visit with your z/OS sysprog. Read up on SMF and RMF data. Take a class on performance tuning focused on a Parallel Sysplex environment.

I strongly recommend that you work with your z/OS sysprogs on this effort.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 2:57 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8210
Location: US: west coast, almost. Otherwise, enroute.

gbaddeley wrote:
MQ Syncpoint VS No Syncpoint, and Persistent VS Non Persisent, are design choices that should be made to meet application requirements for quality of service, transaction integrity, recoverability, performance. etc.

A sys prog can analyse performance and bottlenecks, but should not be tweaking these choices without sign off from the application designers.

There are many other performance resources that can be tweaked that do not affect requirements for syncpoint and persistence, such as MQ buffer pools. You should consult with the z/OS sys progs and z/OS performance specialists.


As a follow on, tune so-called 'low hanging fruit' first. Are the z/OS instances well-provisioned with CPUs, central storage (RAM)? Are paging rates excessively high?

Edit: One of my z/OS MQ clients decided to tune by increasing buffers and buffer sizes, only to discover that aggregate system throughput decreased. Why? The LPAR wasn't provisioned with enough central storage. The paging rate of the z/OS image skyrocketed.

You cannot tune in a vacuum. Focusing on one app or one sub-system while ignoring o/s or sysplex (WLM) images may not yield the results you want, and may end up causing performance problems elsewhere.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data


Last edited by bruce2359 on Wed Feb 07, 2018 4:27 pm; edited 1 time in total
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Feb 07, 2018 4:08 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7476

If waiting on the messages to be committed and made available is not your bottleneck, then eliminating the unnecessary syncpoint may not provide relief. Example, exaggerated to make the point: If you commit every 200 messages, every 5 seconds, a "pulse" of 200 messages becomes available every 5 seconds. If the consuming app can only process 150 messages every 5 seconds, it does you zero good to release the messages individually as they are created versus pulsing 200 of them every 5 seconds.

Before removing the syncpoint, you'd want the app team to explain why they use it to begin with. Would the producing app ever roll back the batch of 200 because they changed their mind and decided not to send them? Or on the consuming side, they picked them up only to release them back? Or maybe they specifically use the syncpoint to achieve this pulsing effect.


And I know your a mainframer. ALL CAPS is where its at in an ISPF session. I had a habit of doing that as well back in the day when I lived in a green screen all day long and came up for air to send an email.[/i]
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 4:31 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8210
Location: US: west coast, almost. Otherwise, enroute.

Since IBM embedded UNIX System Services (1990's) in MVS, the mainframe is no longer upper-case only.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 07, 2018 4:59 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8210
Location: US: west coast, almost. Otherwise, enroute.

Moved to mainframe forum
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2 Page 2 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.