RE: perfomance question -- MIDRANGE-L

Heba,

Looking at the hardware side first:

If you take a look at your disk activity during the posting of a large
batch, you should be able to find out whether you have a hardware
problem.  Use the WRKDSKSTS display to observe the 'percent active'
statistics for all of your drives.  I would see three different
potential results:

1- Most (or all) of your drives are approaching or exceeding their
optimum activity levels (about 40%).  This is a clear hardware problem
and is solved by adding more disk drives or rescheduling the work.
Spawning additional jobs would not help and might make matters worse.

2- A few of your drives are approaching (or exceeding) 40% activity.  In
this case the operating system has determined that new writes should
only go to a few drives or the records being updated are only present on
a few drives.  If this is the case I would suggest looking at the ASPBAL
commands to spread your data over more of the available drives.  The two
relevant commands are TRCASPBAL (Trace ASP Balance) and STRASPBAL (Start
ASP Balance).  If you use the *USAGE parameter, the system will spread
your more active files over the available drives.

3- All of your drives are well under the 40% activity level.  If this is
the case, then your system is not bound by disk I/O and there are no
hardware limitations to spawning additional jobs.

Can you describe more specifically what you mean when you say you have a
'performance slow down'?  Does the entire system slow down, or do you
just require faster throughput for your transaction processing?

If your processor activity is approaching capacity, running additional
jobs without changing anything else would not be of benefit.  Large,
intense batch jobs can often benefit considerably if they have more
memory available.  You could either allocate a larger amount of memory
to the job by putting it in its own subsystem pool or just install more
memory and allow the automatic performance adjustment to put the memory
in the pool.


On the software side:

Would there be any problems with spawning additional jobs and having
them run concurrently?  Some systems have limitations on concurrent
posting and you would need to look into your third-party software to
even see if this is possible.

If your third-party software supports concurrent processing and if
you're not dealing with hardware limitations, then spawning additional
jobs might be the right thing to do.  I would suggest trying to
eliminate the hardware issues first.

Would you provide more specifics on what happens when a large amount of
transactions hits your system?

Regards,
Andy Nolen-Parkhouse

> On Behalf Of heba refaie
> Subject: perfomance question
>
> Hi All,
>
> I have a performance question, one of our interface systems should put
put
> a
> large number of transactions into the as/400 machine and these
> transactions
> should be processed within a certain limit of time.
>
> what we have developed here in-house is just a program that runs as a
> prestarted job every 30min, this program calls another third party
module
> to
> record the transactions...there are some cases that we need to
performa
> lot
> of payment transactions(at the end of month for example) and due to
this
> third party module takes a considerable time because it writes a lot
of
> records in many files we have a performance slow down due to the IO.
>
> I am thinking about converting the prestart job to a DB trigger...
> else can we do? If I spawn 4 jobs instead of one to process the
payment
> does
> it have any positive effect? Any H/W or S/W recommendations to speed
up
> the
> processing?
>
> Thanks in advance for any help
> Heba