Optimizing On-Line Response on MPE
On a multiuser computer system such as the
everyone wants better response time.
The system must juggle as many concurrent user demands
as possible with a fixed amount of CPU, memory, and disc
resources, and still provide acceptable response time to everyone
Thus the task of a performance tuner is to spread the
resources well enough that the user is seldom aware of the other
users. This is the opposite of batch optimization,
where you try to make a single task run as fast as
Most of the effective optimizing solutions
Here are five ideas for improving response time.
Make Each Disc Access Count
Disc throughput is the limiting resource on many HP 3000s
because the disc is one of the last mechanical components of
The disc throughput of the machine is consumed by program swapping, log on's, log off's,
run commands, spooling, and user requests (for databases, files, and so on).
In addition, most functions that use disc I/O consume vast amounts
of CPU time and can make large demands for memory.
You can conserve disc accesses if you
use as few search keys as possible in your data files
(each one adds
disc I/O to maintain indexing data structures),
but not at the expense of frequent
serial scans in your on-line programs.
If the data is relatively static you can afford many more
search paths. And if the on-line users frequently
retrieve that data, more search paths will improve the overall response
Add statistics-gathering to on-line programs and write
the results to a big circular file. Find out what operations
users are really performing. Then use this
data to direct optimization.
Maximize the Value of Each Chunk
Processing a "chunk" of anything generates unavoidable
overhead, so once you decide to do a chunk don't make the
chunk too small. Once you log on, stay on.
Once you open a database, keep it open (don't open and close it
for each transaction). Once you do your locks, get an entire
transaction done (don't lock/unlock around every individual
Design your screen forms to include an entire transaction
(avoid numerous small forms).
Minimize the Run-Time Program Impact
The less impact each individual program has on the system, the
more programs the system can run and still give
good response time to everyone. Pay particular attention to the size
of your data stack; in many languages you can use
dynamic stack storage in a procedure, which
is reusable by the next procedure, rather than using global storage.
Use a tool such as SHOT to monitor program impact.
Know which functions on your system consume a lot of
resources and avoid performing those functions repeatedly in
a loop. On MPE, avoid looping on DBOPEN, FOPEN,
or any networking function.
programs into one that uses subprograms.
Avoid Constant Demands for Execution
All common on-line tasks should
complete in 1-30 seconds when run stand-alone.
Long-running tasks such as compiles and serial scans of
large datasets should be done in
batch jobs, or should at least be dropped into a lower priority. The
advantage of forcing them into jobs is that you can control
the maximum number of concurrent demands and avoid a system
Optimize for the Common Events
Focus your efforts on the 20 percent of your code that
generates 80 percent of the problems. Walk around and be aware of what users are
experiencing. Identify the frequently-used functions.
There is no point in optimizing a program that never runs.
Since the system consumes so much of your machine's resources, learn
to monitor and tune it.