Optimizing On-Line Response

Optimizing On-Line Response on MPE

On a multiuser computer system such as the HP 3000 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 if possible. 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 possible.

Most of the effective optimizing solutions are simple. 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 computer. 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 time. 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 update call). 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, CREATEPROCESS, or any networking function. Combine several 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 overload.

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.