I agree. But the question remains. How does WLM manage a response time that is longer than the policy adjustment interval? Is it only based on ended transactions at that time (which would seem logical).
I've also seen a lot of recommendations from various sources talking about short batch, which is what gave rise to the question. Specifically the recommendation used 5 initiators as the example. Also it doesn't matter if it is percentile or average response time. What makes me wonder is that it basically tenders the percentile useless. For example, if I have an average response time of 1 sec, then it is easy to see that enough transactions would end in an interval to provide samples to evaluate. However let's also say that there are some transactions that will experience a response time of 60 seconds (and stay in the same period). In fact, this can happen with USS where transactions may show a response time of 20 seconds. Since these end during different policy adjustment intervals, it seems that they are only a sporadic effect, because during the interval when none end, the average response time would hold. During the intervals when they do end, the percentile would be applicable. Yet wouldn't this cause me to perpetually fluctuate between exceeding goals and meeting them? After all during the intervals when I have no long running transactions ending, I would show 100% meeting goals and exceed by goal. Yet I don't recall ever seeing this kind of behavior. Sent from my iPhone > On Feb 15, 2018, at 6:17 AM, Allan Staller <[email protected]> wrote: > > Response time goals for batch do not (IMO) make any sense. > > WLM is predicated on having enough samples to make an informed decision. If > you only have 1 or 2 samples (ended transactions) in an interval, that is not > statistically valid. > I would suggest a velocity goal be used in its place. > > If queue time is needed to be considered, the I would expand the suggestion > to include WLM managed initiators. This will change the velocity calculation > to include queue time as part of the delay. > > Suggested reading: ftp://public.dhe.ibm.com/s390/zos/wlm/WLMvelocity.pdf > > HTH, > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Gerhard Adam > Sent: Wednesday, February 14, 2018 9:40 PM > To: [email protected] > Subject: Re: WLM and response time > > Well, this may seem like an obvious answer, but I can't tell if I'm confusing > myself or missing something. > > If I use a long response time (like 10 minutes for batch), then I would think > that I only consider that during the Performance Adjustment interval in which > the transaction ends. Yet that raises the question that if I have multiple > jobs in such a service class, then over what interval must they end to > provide a meaningful metric? Assuming they would all end within a 10 second > window seems implausible, so how can a response time goal realistically be > managed at such high values? > > In addition I recently read that even transactions that haven't ended can be > used in the evaluation of goals, but that doesn't make sense since, by > definition, they haven't ended. Yet this is what percentile goals are > supposed to represent. > > So I guess my question involves how a policy adjustment interval addresses > transaction that run longer than the time between intervals, or is it merely > that they are only examined during the interval they actually end in? > > Adam > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
