# Performance Benchmark Report ## Environment ### Hardware #### ‘Rather Snappy’ Laptop - Dell Precison M3800 Laptop - 4x Intel(R) Core(TM) i7-4712HQ CPU @ 2.30GHz - 12Gb RAM - SSD #### ‘Ole Workhorse’ server 8x Intel(R) Xeon(R) CPU X5550 @ 2.67GHz 16Gb RAM Magnetic drive, XXX RPM ### Software - Arch Linux OS - glibc 2.26-11 - python 3.5.4 - lmdb 0.9.21-1 ### Benchmark script [Generator script](../../util/benchmark.py) The script was run with default values: 10,000 children under the same parent, PUT requests. ### Data Set 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: - 50 triples have an object that is a URI of an external resource (50 unique predicates; 5 unique objects). - 50 triples have an object that is a URI of a repository-managed resource (50 unique predicates; 5 unique objects). - 100 triples have an object that is a 64-character random Unicode string (50 unique predicates; 100 unique objects). ## Results ### ‘Rather Snappy’ Laptop #### FCREPO/Modeshape 4.7.5 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 #### LAKEsuperior Alpha 6, LMDB Back End 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%) ### ‘Ole Workhorse’ server #### FCREPO 0:47:38 running time 0.285" per resource (100%) Retrieval of parent resource: 9.6" (100%) #### LAKEsuperior 1:14:19 running time 0.446" per resource (156%) Retrieval of parent resource: 5.58" (58%) ## Conclusions 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.