Perhaps the better performing system had a decent portion of the database
in memory.

The latest versions of STORE seem to free up all pages which were stored.

Perhaps RESTORE does the same thing (being a part of the same program).

Otherwise, normal application use would generally result (memory pressure
dependent) in a decent working set of the database being memory resident.

To ensure fair testing, I would use the Allegro free utility FLUSH before
each run.

        http://www.allegro.com/software/hp3000/allegro.html

An alternative (assuming the working set is smaller than the total number
of pages generally available) is to run the programs twice (assuming they
are re-runable).  After the first pass, the pages would be more likely
to be memory resident.  That will speed up the second pass.

I generally see a large reduction in elapsed time (sometimes > 75% for
my tests) and a decent reduction in CPU time (around 25%) if the pages
are already memory resident.

That is quite dependent upon the amount of application code executed
relative to TurboIMAGE and system code.  Also quite dependent upon
relative speeds of the processor(s) and I/O rates.

For your environment there is also the question as to number of effective
drive spindles (I say that to account for RAID).

It's somewhat of a shame that STORE frees up pages which had already been
memory resident.

After the night's backup, database performance is much lower until a
decent working set gets brought back into memory.

Also, the Allegro free utility RAMUSAGE is also quite handy.  It will show
the number of pages of TurboIMAGE data which are memory resident.

Sorry this rambled, but there are so many things which effect performance
benchmarking.

Rick

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *