RE: System Analysis Suggestions

[Brian Piotrowski <bpiotrowski@xxxxxxxxxxxxxxx>]

That's exactly the other path I was going to take as well - I still have to look at the IIS box to see what is going on there.

Ultimately, I would like to run everything on the 400, but as it stands right now our webserving functions on the 400 run like an absolute pig - I think I will need to optimize those settings as well before I consider changing platforms.

/b;

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Monday, August 10, 2009 6:21 PM
To: Midrange Systems Technical Discussion
Subject: Re: System Analysis Suggestions


> DSPACTPJ SBS(Qusrwrk) PGM(QZdasoinit)


If CPU utilization is bumping up against 100%, you might actually be better off limiting the number of QZDASOINIT jobs so that Web applications and other database clients don't overwhelm a CPU.  It would be better to queue requests rather than run too many servers, which overextend a CPU. Use MAXJOBS parameter on CHGPJE command.

Performance monitors tell you which jobs are using which resources, but how do you know if a resource is a bottleneck?

Monitoring database server jobs often don't shed much light because lots of different applications may be using the same QZDASOINIT jobs.

Performance monitors more or less point a finger back at badly performing applications.  On the other hand, application developers are admonished against prematurely optimizing their applications.

It seems that either way you end up spending money to add capacity to a server, rewrite or move to better performing applications.  There's only so much you can do via configuration options.  Take the suggestion to reduce the priority of QZDASOINIT jobs - it may please green-screen users, but anger database server clients.

It appears that a good chuck of Brian's applications are Windows based Web applications - but he's asking what he can do to tune IBM i performance.  Why not tune Windows or IIS performance, instead?

-Nathan




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.