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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.