umgeher/leveled
0
Fork 0
Code Issues Pull requests Releases Activity Actions

Split out pre-riak test report

Browse source
This commit is contained in:
martinsumner 2017-02-02 13:05:09 +00:00
parent 1e2db49af3
commit b5ef0d8fd5
2 changed files with 23 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -32,6 +32,6 @@ At the initiation of the project I accepted that making a positive contribution
The target at inception was to do something interesting, something that articulates through working software the potential for improvement to exist by re-thinking certain key assumptions and trade-offs. The target at inception was to do something interesting, something that articulates through working software the potential for improvement to exist by re-thinking certain key assumptions and trade-offs.
[Initial volume tests](docs/VOLUME.md) indicate that it is at least interesting, with substantial improvements in both throughput and tail latency when compared to eleveldb - in scenarios expected to be optimised for leveled. Note, to be clear, this is statement falls well short of making a general claim that it represents a 'better' Riak backend than leveldb. [Initial volume tests](docs/VOLUME.md) indicate that it is at least interesting, with substantial improvements in both throughput (73%) and tail latency (1:20) when compared to eleveldb - in scenarios expected to be optimised for leveled. Note, to be clear, this is statement falls well short of making a general claim that it represents a 'better' Riak backend than leveldb.
More information can be found in the [volume testing section](docs/VOLUME.md). More information can be found in the [volume testing section](docs/VOLUME.md).

22
docs/VOLUME_PRERIAK.md Normal file
View file

@ -0,0 +1,22 @@
# Volume Testing
## Parallel Node Testing
Initial volume tests have been [based on standard basho_bench eleveldb test](../test/volume/single_node/examples) to run multiple stores in parallel on the same node and and subjecting them to concurrent pressure.
This showed a relative positive performance for leveled for both population and load.
Populate leveled | Populate eleveldb
:-------------------------:|:-------------------------:
![](../test/volume/single_node/output/leveled_pop.png "LevelEd - Populate") | ![](../test/volume/single_node/output/leveldb_pop.png "LevelDB - Populate")
Load leveled | Load eleveldb
:-------------------------:|:-------------------------:
![](../test/volume/single_node/output/leveled_load.png "LevelEd - Populate") | ![](../test/volume/single_node/output/leveldb_load.png "LevelDB - Populate")
This test was a positive comparison for LevelEd, but also showed that although the LevelEd throughput was relatively stable it was still subject to fluctuations related to CPU constraints. Prior to moving on to full Riak testing, a number of changes where then made to LevelEd to reduce the CPU load in particular during merge events.
The eleveldb results may not be a fair representation of performance in that:
- Within Riak it was to be expected that eleveldb would start with an appropriate default configuration that might better utilise available memory.
- The test node use had a single desktop (SSD-based) drive, and the the 'low' points of eleveldb performance were associated with disk constraints. Running on more genuine servers with high-performance disks may give better performance.