RE: Interactive Response Time -- MIDRANGE-L

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: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of prumschlag@phdinc.com
| Sent: Thursday, December 13, 2001 11:11 AM
| To: midrange-l@midrange.com
| 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