RE: Interactive Response Time

["Andy Nolen-Parkhouse" <aparkhouse@xxxxxxxxxxxx>]

Phil,

It sounds like you have some work to do and pulling out the Performance
Tools manuals might be a good start.  Perhaps more important would be to
determine (and get agreement upon) an acceptable measure of performance.
The thirty-second limit on any single interactive transaction proposed
by your president is not realistic.  Any transaction of that duration is
either a fluke, a batch job running interactively, or a sign of a system
which should have been upgraded a long time ago.  What would make sense
to me would be something like average response time of two seconds or
less during any half hour period.  It is a negotiation process with some
politics involved.

Then it sounds like it is your job to both understand how to measure and
document performance.  The tools are a good place to start and the
manuals provide the guidance necessary to interpret the data.  There
_are_ hundreds of ways to approach tuning, but generally only a few are
appropriate for a given situation.  Sometimes you can trade off the
pain/expense of an application rewrite for the pain/expense of a
hardware upgrade, but generally speaking the correct answers will
present themselves clearly once you have appropriate performance data
and a knowledge of the various performance thresholds.

I don't think that there is much in the way of a 'quicker/easier/better
way to approach this' other than to do as you have described.

Regards,
Andy Nolen-Parkhouse


> 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