8x Intel(R) Xeon(R) CPU X5550 @ 2.67GHz 16Gb RAM Magnetic drive, XXX RPM
The script was run with default values: 10,000 children under the same parent, PUT requests.
Synthetic graph created by the benchmark script. The graph is unique for each request and consists of 200 triples which are partly random data, with a consistent size and variation:
15'45" running time
0.094" per resource (100%—reference point)
3.4M triples total in repo at the end of the process
Retrieval of parent resource (~10000 triples), pipe to /dev/null: 3.64" (100%)
Peak memory usage: 2.47Gb
Database size: 3.3 Gb
25' running time
0.152" per resource (161%)
Some gaps every ~40-50 requests, probably disk flush
Retrieval of parent resource (10K triples), pipe to /dev/null: 2.13" (58%)
Peak memory usage: ~650 Mb (3 idle workers, 1 active)
Database size: 523 Mb (16%)
0:47:38 running time
0.285" per resource (100%)
Retrieval of parent resource: 9.6" (100%)
1:14:19 running time
0.446" per resource (156%)
Retrieval of parent resource: 5.58" (58%)
LAKEsuperior appears to be markedly slower on writes and markedly faster on reads. Both these factors are very likely related to the underlying LMDB store which is optimized for read performance.
Comparison of results between the laptop and the server demonstrates that both read and write performance gaps are identical in the two environments. Disk speed severely affects the numbers.
Note: As you can guess, these are only very partial and specific results. They should not be taken as a thorough performance assessment. Such an assessment may be impossible and pointless to make given the very different nature of the storage models, which may behave radically differently depending on many variables.