Re: Batch Immediate CGI =/= Interactive monster?

What is the run priority for these CGI jobs?
What is the time slice for these jobs?

Also look at WRKSYSSTS

Send us a screen print at the Advanced Assistance level. Make sure the Elapsed time is at least 2 or 3 minutes. You are looking for a high number of faults or anything in the two right hand columns. What system pool are these jobs running in? Does it have enough memory? Are enough activity levels configured?

Look at WRKDSKSTS

Do any of your disk units have a number 40 or greater in the %Busy column? Once again your time frame needs to be at least 2 or 3 minutes.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: midrange-l@xxxxxxxxxxxx
From: Luke Gerhardt
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 09/19/2011 12:07PM
Subject: Re: Batch Immediate CGI =/= Interactive monster?


On 9/19/2011 11:48 AM, midrange-l-request@xxxxxxxxxxxx wrote:

date: Mon, 19 Sep 2011 08:40:16 -0700 (PDT)
from: Nathan Andelin<nandelin@xxxxxxxxx>
subject: Re: Batch Immediate CGI =/= Interactive monster?

 From: Luke Gerhardt
 I've got a CGI job with two threads

That's odd, the vast majority of CGI jobs in the world are single threaded. Did you write a multi-threaded CGI job? Or, are you referring to 2 single threaded jobs?

Sorry, yes.  Two single-threaded jobs.  I have two sites using the CGI
program, so that's probably why there are two 35% jobs.  There are
others with the same name running under the same subsystem, but not at a
level approaching these two.

 Yesterday, a user?complained of a 7 minute wait changing between two open sessions

That normally occurs when the client can't make a connection to the HTTP server, usually because other users have tied up all the connections, possibly because the HTTP server is maintaining persistent connections, according to the configuration directives used.

This user doesn't even use the CGI system at all.  He was using two 5250
**interactive* *emulation sessions.  The concern from management was
that the CGI jobs are crushing the system and causing this user's
slowness issue.

??each running at around 35%

This makes me suspect that you're actually talking about 2 jobs, as opposed to a single job running 2 threads. The 35% is based on what the job is doing, and you haven't given us any indication of what it might be doing. Serving a huge report? Downloading huge files? Running un-optimized queries against a huge database?

The CGI process runs an auto-refreshing display of production orders,
allows the user to mark them as produced, and to print shipping labels.  
It's native RPG file I/O with some prototyped calls and client-side
javascript.  Most of the time it is waiting for a js timer to elapse to
tell it to reload the screen.

I was hopeful that there was a clear explanation I can pass on that
explains 1) why these jobs chew up a lot of %, and 2) what would happen
when an interactive job came on the scene needing % for itself.  Since
the priority is different, won't these jobs drop quickly and allow the
standard interactive job to do what it needs to?  I suggested that
already, but was met with the response that it may take a while for the
interactive job to get enough resources to get up to where it gets more
priority than the CGI process.