RE: Interactive Response Time -- MIDRANGE-L

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