Re: Interactive Response Time

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.
>
>