There is no inherent difference between job types...a job is a job is a job...

Now, by default, specific jobs are defined to use specific classes
(*CLS) and the attributes of the classes may cause the run time
attributes of a job of one type to differ from another...but any of
that can be (and arguably should be) customized...

Default interactive class uses a priority 20, whereas default for CGI is 25...

Assuming there's nothing else running, having a couple of threads
taking 35% of CPU is not a problem, in fact you can make the argument
that they should be taking 100%. After all, unless the CPU is at
100%, you're wasting cycles doing absolutely nothing. Since they
aren't you know the jobs are waiting on disk i/o. The real question
is are they doing useful work efficiently? You'd need to run some
performance traces or SQL monitors to determine that. It may not
matter, till you get to the point where you've got other work waiting.

Lastly, performance of switching between open sessions is _ALWAYS_ a
function of the load on the PC, not the i.

HTH,
Charles

On Mon, Sep 19, 2011 at 7:07 AM, Jim Oberholtzer <midrangel@xxxxxxxxxx> wrote:
What version of the OS?

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 9/19/2011 5:49 AM, Luke Gerhardt wrote:
I've got a CGI job with two threads, each running at around 35% when
/nothing else /is active.  They're listed as 'BCI'-type jobs.  This CGI
system has been in place for about 6 months.  Yesterday, a user
complained of a 7 minute wait changing between two open sessions on his
relatively new Windows PC and concerned persons are pointing at this CGI
system as being a possible culprit due to it having high %s when it's
running alone.

I've tried to delay the notion of scrapping it and writing a PC program
by manually dropping the priority on those jobs to 8.  But...how can I
explain it using so much of the system?  What are the effects of this
type of job, compared to a full-bore interactive job chewing up 70% of
the system?

Thanks!!
--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.