Re: Interactive Response Time

[prumschlag@xxxxxxxxxx]

Combined response to all who offered advice (in random order):

First some general comments.
   The solution will come in two parts.  Since I really can/should not satisfy
   his exact request, first I need to develop some measurements that I can track
   so that I can show progress.  However, once I begin to monitor the
   measurements, I will need to be able to identify areas for improvement.  The
   charts that track response time without a method for identifying the problems
   will not do me any good.  In fact they could be used as evidence that I am
   not making progress.

   My general observations tell me that the most likely cause of our random slow
   response times (in order) are:
   a)  Program related (JDE programs try to be all things to all people:  Lots
   of options, but performance suffers.)
   b) Two CPU-hog jobs running in batch at the same time.
   c)Too many people hitting enter at the same time (eg, 50 people signing on at
   shift-change.)
   d) Program related (JDE programs will sometimes wait for a record to unlock
   instead of returning control to the user.)

   I suspect we have a multitude of these situations, not just a few.

I like David's comparison to accident free driving.  *I* like the comparison,
but I have tried this type of explanation with the president before without much
luck.  His response would be "but I'm not talking about a car......".

Rob:  Thanks for the offer to recreate on your 840.  I will keep that one in my
back pocket.

I considered the PM400e graphs from IBM.  That would give me the measurements,
but I am afraid the information would not be current enough to identify what was
causing the problem.  It might tell me who "had" a response time problem, but
not necessarily what "caused" the problem.  Asking any user (including me) what
he was doing yesterday at 10:43 is pretty hopeless.

Because of where I suspect the real problems are (see above), it's probably too
soon to get into adjusting pool sizes.  That will come later.

Measuring response in time buckets (0-1, 1-2, 2-4, 4+) is a great idea.  That's
likely to be where I go first.

Based on Ops Nav, it appears that CFINT is rarely a problem here.  It's usually
hanging around, but doesn't take up much CPU (most of the time).

Thanks to all.  JT and I are going to try to collaborate on this.  We will keep
you posted.

Phil