|
I don't think it is unreasonable for the president (or any user/manager) to request some planning to solve a problem such as an ?infrequent? 2 minute response time. As an extreme example, suppose that 2 minutes was to a telephone operator trying to relay an immediate response to a waiting customer? >From your statements, the 2 minute response is very abnormal to you system, and normal is less than 2 seconds. Any extreme response, not planned or expected indicates a problem. To jump on disk or memory or any other area, without some analysis most likely will not solve the problem. Money spent & not solving the problem will create more problems for you. Bad program design, or record locking can bring an 840 to it's knees, let alone a 730. You've got OPS Nav looking at average response. You just need more detail. What release? Do you have Performance Tools loaded? At V4R5, this is what I've got: GO LICPGM and option 10 will display products you have. 5769PM1 *BASE Performance Management/400 (the free one) 5769PT1 *BASE Performance Tools for AS/400 (the paid for licpgm) I would suggest the quickest answer may come from the user, like "every time I run xxxx the system gets slow". The free tool, PM1, has some basic commands STRPFRMON, ENDPFRMON DSPPFRDTA, and a bunch of reports. I do like the detail in the PT1 product. For the long term, I run the pfrmon regularly, and look for problems. I suspect you will find your problem, and will be able to plan to control it. At a previous customer, our performance plan was based on both expected average response, and a "not to exceed" response time. Peak work days, month end, anything out of the oridinary had to be accounted for. The goal was always that users should never have to wait, and that is not unreasonable!. And I would expect goals for green screen, client/server, lan, wan, web. btw-current customer today, working on fixing "old" code for performance, turned a 10 minute batch job, 30 times a day into 1 second each(the right access path). Feels great! (am not a performance guru, but had to deal with a lot of issues) jim franz ----- Original Message ----- From: <prumschlag@phdinc.com> To: <midrange-l@midrange.com> Sent: Thursday, December 13, 2001 11:11 AM 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 > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.