Magma read performance

[Chris Muller]

There has been interest in Magma's read and query performance lately,
so I thought I would share results of a recent benchmark test.

It's an actual application which does very heavy reading and writing
to a Magma repository.  This test was 24GB of repository work, over
two days.  My goal was to determine, once the persistent model becomes
many times the size of RAM and HD access appeared to become the
limiting factor:

  - how fast is Magma, in terms of "objects per second" and in
"kilobytes per second"?
  - how fast is this relative to the speed when the repository was empty?

Conclusion:

  - Magma started at 4K objects per second (empty repository), 282K per second.
  - Finished with 2.3K objects per second (6GB repository), 750K per second.
  - Memory consumption by the image never exceeded 300MB.

It is important to note, these times are from the client MagmaSession
point-of-view, including the full server roundtrip plus
materialization.  Also, as can be seen from the attached data, there
were many requests which only brought back one or two objects which,
while dramatically lowering the overall reported throughput, is
actually a real-world scenario for applications.

Verbose description:

When the test first started the repository was tiny, and there were
only ~4K server requests during a 5-minute monitored period.  The
total number of objects read across all ~4K requests was ~17M for an
average throughput of 4K objects per second (ops).  As the model grew
in size and complexity, more and more objects during the 5-minute
monitored intervals were required to perform application-posting of
the same number of input records; doubling to ~8K server requests
during a 5-minute period, however only a few more objects brought back
(total 21M), for an average of 2500 ops.  32 hours after that, the
rate of reads dropped to about 2300 ops.  This is due to two factors:

  - the objects were larger (e.g., more pointers to other objects)
  - they were less clustered (having been replaced with objects which
could not be co-located with the original object)



The fact that objects got bigger (e.g., more pointers to other
objects) is corroborated by another stat, "the number of *bytes* per
second" read off the HD in order to access those objects.  Initially,
when the test first started, there were about 4K *requests* for
objects in one of the first five-minute periods, which were read at a
rate of 282K per second.  24 hours later, there were only 2 times as
many requests for objects, but were read-and-materialized at a rate of
750K bytes / second.


 - Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bench.txt.gz
Type: application/x-gzip
Size: 73875 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/magma/attachments/20101124/4a5c7824/bench.txt-0001.bin