Re: Batch Immediate CGI =/= Interactive monster?

Given your description, the only time you should see CPU being used is
right after the screen is refreshed and only for however long it takes
to refresh the screen...

I would expect to see a high CPU usage only for few milliseconds...

If that's not the case, you've got something else going on...either
the RPG is doing more than you think or the java script is doing
something..the auto-refresh would be my first suspect.

You say the auto-refresh is using a javascript timer, which is what
I'd consider to be the right way to do this. However, the high CPU
behavior you describe sounds more like a loop is being used. Even
then, the loop would have to be on the i side, to see high CPU on the
i. If it was in the javascript, you'd see high CPU on the PC.

The time it takes the i CPU to switch between tasks is negligible
(unlike other OS's)... the only time it's not is if teh job being
switch too has been paged out of memory. You could prevent this by
making sure your CGI jobs are running in there own memory pool
separate from the interactive jobs.

HTH,
Charles

On Mon, Sep 19, 2011 at 12:01 PM, Luke Gerhardt <lgerhardt@xxxxxxxxx> wrote:

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.