Jerry, Phil: Given the situation, that response-time is normally under 2 seconds, I think even a blind squirrel is gonna be able to find this nut: JDE and possibly other apps are running batch jobs under interactive. Meaning, what would normally be considered a batch-friendly job is being run interactive. So on second thought, I think a there are a couple interim steps that would be MUCH cheaper and quicker to implement, and accomplish the following objective: Show the President a rapid response to the situation. 1) Turning on job accounting; and/or 2) Taking snapshots of the system through WRKACTJOB API; 3) Importing data into Excel to make a nice presentation. Option 1) Turning on job accounting. I have done some work with this, so it will be an easier way to START getting a handle on the problem. This would also grab SOME measurements, with the bare minimum of processing time. The only rub is that, to do this effectively, it would be a great benefit if users tried to assist in this process. They may be unwilling or unable... But if they could try to signoff, and sign back on, for those jobs that they've found to be the worst offenders: a) they will help identify the bottle-necks, themselves; b) we can use this info take PM measurements during these worst jobs, rather than at random and/or throughout the day. >From the PT manual "When you can clearly describe the problem and have determined when it seems to occur, you are ready to collect performance data to be analyzed by the advisor. If possible, focus on collecting data for one problem at a time." Plus PM, itself, will impact performance, if done excessively. Plus, we can show some results, with or without users assistance, while we're looking into PM. I would think we could get at least a decent idea, and be able to lay out a decent presentation, of the extent of the problem. We could only get average numbers, rather than min/max response time, unless the users could assist in identifying the worst-offending jobs as an individual job. Option 2) Taking snapshots of the system through WRKACTJOB API. I have code to do this, and done queries against the files produced. Code is stale, so would need to be reviewed, but this would be the quickest to implement. Most of the comments above apply here. Option 3) Importing data into Excel to make a nice presentation. I, personally, wouldn't normally go to this trouble... But for the President, I wouldn't recommend any less. As far as the Performance Tools: Jerry, do you know if Dave I. (who you mentioned to me a while back) is still looking for work...?!? He might be able to give us a HUGE jump-start on this, and I'd like to meet him anyway... (Maybe we could pay him, for his trouble...?) I skimmed of collecting the data and displaying the results, as I'm hoping Dave I. can save A LOT of time. I sure THOUGHT I'd seen APIs, but cannot find them right now... Maybe it was when I was looking at SystemView... There is an *OUTFILE capability, if we can't locate the APIs. Again, given Phil's situation, I would go to the minimum time and expense, as far as PT goes. I would view this more as a first-step in us learning about them, Jerry. AFAIK, PT has the advantage over the above suggestions, in that it captures the total response time, from end to end, rather than just the processor-related response-time. (I don't think the point is lost on you, Jerry, that these ERPs are gonna provide an IDEAL opportunity for a tool that runs interactive jobs in batch. I believe the group is seriously gonna need to start thinking about having an extended and VERY limited initial roll-out. This thing could, and almost necessarily will, implode on it's own success... No need to start discussing it, until we get a whole lot closer, but we need to start thinking about it... This would also give IBM and the market an extended transition period. NOT to be pre-announcing vaporware, but to under-promise and hopefully over-deliver, eventually.) Let us know what you think, Phil, either on or off-list... BTW, we're fairly generous... But in this case, this is work we were planning on doing anyway... (And both of us are too swamped to be looking for any additional work, at the moment, so we're not trying to pull a bait and switch on ya...;-) jt PS Just saw Phil's post, which I'll forward along with this to Jerry. You hit the nail, Phil, when you said "once I begin to monitor the measurements, I will need to be able to identify areas for improvement." My experience is that by identifying the worst-offending and easiest-to-fix jobs, you can see a lot of perceived improvements, in a short time. This is clearly a case where the perception is even far more important than usual. | -----Original Message----- | From: firstname.lastname@example.org | [mailto:email@example.com]On Behalf Of jt | Sent: Thursday, December 13, 2001 11:54 AM | To: firstname.lastname@example.org | Subject: RE: Interactive Response Time | | | Phil, | | Since you're dealing with the President, this sounds like a great | opportunity to turn a problem into a solution... | | You wrote "Here is my question (finally). Other than pulling out the | Performance Tuning manuals, is there a quicker/easier/better way | to approach | this?" | | Ya... I can pull out the PT manuals...! I've got the tools, but never | looked at 'em. As it happens, I'm needing to measure response | times myself | (min, max, avg, yada, yada, yada). | | | The key question is HOW SOON do you need this. May not be a fit | (what with | holidays and all)... However, Sprout says he might have some time to | help... but then he's always saying that... ;D | | | If you want to provide some more specifics, I'm putting together an e-mail | to Jerry shortly. He usually estimates ALL projects to take a week or two | and cost $10K... Doesn't matter WHAT it is... We refer to that as | "Sprout-time" because it doesn't always correspond to time as | measured by a | clock...;D But even he couldn't take a swag at a time estimate, in this | case. | | We believe, but don't know for a fact, that the perceived | response time can | be captured and measured. Just saw Michael Crump's post, and we think we | can pin-point those apps with design flaws. I've had similar experiences | with JDE (the old F-version "World?" product), as they run a lot of things | interactive that I wouldn't... | | Not gonna address that problem with this Performance Tools utility, but | should at least be able to measure the ACTUAL extent of the problem, and | identify the choke-points. No cost to you, but maybe you can put | the bug in | the President's ear, for him to tell his peers in the industry | how this list | solved him a problem...! | | jt | | | | -----Original Message----- | | From: email@example.com | | [mailto:firstname.lastname@example.org]On Behalf Of email@example.com | | Sent: Thursday, December 13, 2001 11:11 AM | | To: firstname.lastname@example.org | | Subject: Interactive Response Time | | | | | | | | | | I have been asked to come up with a plan so that no user will | | ever have to wait | | more than 30 seconds for an AS/400 interactive response. The | | request (from the | | company president) was based on a completely out-of-context | | observation of one | | user who had to wait 2 minutes for a response to one particular | | screen on one | | occurrence. The president's intent is good, he just does not | | know what he is | | asking for. | | | | Because I don't believe his request can be or should be satisfied | | as he worded | | it, I am planning to reshape it into an initiative to monitor | | both average and | | longest response times, set goals (not guarantees) for both, be | | able to explain | | exceptions, and propose a series of solutions that are most cost | | effective. I | | will report this to him on a monthly basis. Sounds pretty noble, huh? | | | | Just for the record, Ops Navigator shows that throughout the day | | our average | | response time is normally under 2 seconds, and often under 1 | | second. We are | | running JDE World on a 730 dual processor. | | | | I am sure there are hundreds of ways to approach this (bigger | | processor, more | | memory, more disks, better management of file sizes, better | | scheduling of batch | | jobs, LPAR(?), separate test box, programming changes, yada, | | yada, yada.). | | | | Here is my question (finally). Other than pulling out the | | Performance Tuning | | manuals, is there a quicker/easier/better way to approach this? | | Remember, my | | goal is to develop meaningful performance measures and be able | to identify | | solutions to performance problems. | | | | Thanks. | | Phil
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.