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.