Here's an example of why I'm questioning this. This is from a book by Robert Vaupel. I know he's knowledgeable, but the explanation is confusing.
Using an average response time example he says "The running or in-flight transactions are also captured in order to make sure that long running and not ending transactions are used for managing the service class too.". Why should a transaction that hasn't ended be relevant? Sent from my iPhone > On Feb 15, 2018, at 10:34 AM, Allan Staller <[email protected]> wrote: > > IIRC, WLM only uses ended transactions for the policy adjustment cycle. > > Further suggested reading SYSTEM Programmers Guide to WLM: > > www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Gerhard Adam > Sent: Thursday, February 15, 2018 11:25 AM > To: [email protected] > Subject: Re: WLM and response time > > 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 > > ---------------------------------------------------------------------- > 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
