From: boone@convex.cl.msu.edu (Dennis Boone)
Newsgroups: comp.sys.prime
Subject: Re: tuning
Date: 1 Sep 92 22:18:51 GMT
Organization: Michigan State University, East Lansing

In article <9208282012.AA17109@usenet.rpi.edu> Info-Prime@Blx-A.Prime.COM writes:
>This machine has been running fairly
>quickly for the past year. The application is COBOL85 and
>MIDASPLUS. There are about 30 users logged in, all using the same
>login id and therefore the same CPL that presents a menu. This menu
>has several selections with each selection invoking a separate
>.RUN cobol85 program. The application is one of registering students,
>mostly from the phone. Once the program is loaded
>from the menu, the response time is very good. The problem seems
>to be when the user has to stop one .RUN program and return to the CPL
>menu to invoke another .RUN. The time to actually stop the first
>.RUN varies from 15 seconds up to 90 seconds. Once the program does
>stop and the cpl menu returns, the next .RUN the user selects also takes
>about the same time to load and start to execute. Again, once this
>second program starts, it is quite fast at accepting terminal input.

There were a couple of people who pointed out that CPL is slow.  Even though
you are compiling it, it's still probably not the quickest thing in the
world unless its a real simple program.  Remember that CPL lets you do
string substitution and other difficult-to-compile-efficiently things.
Much of the "compilation" process is probably just tokenizing.

The shop I worked for set up an external login program which called COMI$$
to start a cominput file.  The same trick might help you with the large
login slice someone else mentioned.

>I am currently running Primos 23.1 with old AMLC ports plus two
>async line printers(not used very much and I don't feel are a factor),
>1 ethernet controller running TCP/IP (I only use the amlc
>ports for the above application as the etherent connections go to a
>teaching lab which is not used when the above application runs).

Check your AMLC clock port rate (last AMLC port on the system) to make sure
the baud rate is 300, or 110.  What is your %AMLC?

>I have run usage quite a lot which shows my PIO/S at a max of 30 but mostly
>below 20, CPU runs at about 20-30%, %miss is less than 10% all the time,
>%io is less than 15%. I set E -TS 50 and CHAP ALL -TS 2000. I was
>originally running 24MB but added 8 more from another machine to max out
>at 32MB. If this extra 8MB had any affect, my users didn't see it.

Make sure you have told Primos the extra memory is there.  This can be
extracted from USAGE reports, or find the CONFIG directive.

Definitely try to balance the I/O load on your disks and controllers.
Specifically, split paging, programs, and data onto separate spindles.
Perhaps posting a few representative USAGE snapshots would help.

Investigate sharing the very most heavily used sections of code.  This applies
less if you are using EPFs.  Check for pure vs. impure code and similar
things that might defeat the sharing benefits of EPFs.  Try to reduce the
size of the .RUN modules so they take less time to load.  Increase the 
working sets of your users.  Make sure there is no debug data in the
the programs.  Can you register your EPFs?  If they are registerable
EPFs and the aren't registered they aren't shared...

Carefully: investigate the benefits of reordering the libraries listed
in your search rules to bring the Cobol and Midas items to the top.
The suggestions Prime makes are at least a little flexible.  Try
putting -STATIC_MODE at the top.  Use MSR to find out how to improve
the ordering of your search rules.

Try maxing out the NVMFS directive in CONFIG.

Look into an upgrade to Primos 23.2 or .3.  Newer is often better :-)

Remember that opening files is slow, and MIDAS files are segdirs which are
really LOTS of files.  If the program opens files before displaying any
user output, the load time looks longer.

Most important: keep chiseling.

Dennis
--
 == If you choose not to decide, you still have made a choice. ==
Newsgroups: comp.sys.prime