// Comma-separated list of operations to run in the specified order
// Actual benchmarks:
// fillseq – write N values in sequential key order in async mode
// fillrandom – write N values in random key order in async mode
// overwrite – overwrite N values in random key order in async mode
// fillsync – write N/100 values in random key order in sync mode
// fill100K – write N/1000 100K values in random order in async mode
// deleteseq – delete N keys in sequential order
// deleterandom – delete N keys in random order
// readseq – read N times sequentially
// readreverse – read N times in reverse order
// readrandom – read N times in random order
// readmissing – read N missing keys in random order
// readhot – read N times in random order from 1% section of DB
// seekrandom – N random seeks
// seekordered – N ordered seeks
// open – cost of opening a DB
// crc32c – repeated crc32c of 4K of data
// Meta operations:
// compact – Compact the entire DB
// stats – Print DB stats
// sstables – Print sstable info
// heapprofile – Dump a heap profile (if supported by this port)
// A comma-separated list of operations to run in the specified order
// Actual benchmark:
The difference between synchronous and asynchronous:
Asynchronous: Write to the memory and report that the write is successful, and write to the disk is ignored.
Synchronization: The write must be written to disk to be considered successful.
Asynchronous write operations are typically a thousand times faster than synchronous write operations.
A combination scheme is also possible where every Nth write is synchronous, and in case of a crash the bulk load restarts just after the last synchronous write completed by the previous run. (Synchronous writes can update a marker describing where to restart on a crash.)
WriteBatch provides an alternative to asynchronous writes. Multiple updates can be placed in the same WriteBatch and applied together using synchronous writes (ie, write_options.sync set to true). The additional cost of synchronous writes will be amortized across all writes in the batch.
leveldb::WriteOptions write_options;
write_options.sync = true;
db->Put(write_options, ...);
// fillseq – in asynchronous mode, write N Vs sequentially in the order of keys
— under normal circumstances, leveldb chooses asynchronous mode. (sequential write, using: writeSeq)
// fillrandom - write N values in random key order in asynchronous mode
---- use writerandom
// overwrite - overwrite N values in random key order in asynchronous mode
// fillsync - writes N/100 values in random key order in synchronous mode
// fill100K - writes N/1000 100K values in random order in asynchronous mode
// deleteseq - deletes N keys in order
// deleterandom - delete N keys in random order
// readeq - read N times in sequence
// readreverse - read N times in reverse order
// readrandom - read N times in random order
// readmissing - read N missing keys in random order
// readhot - read N times in random order from 1% of the DB
// seekrandom - N random seeks
// seekordered - N ordered seeks
// open - cost of opening the database
// crc32c - repeated crc32c for 4K data
// meta-operations:
// compact - compacts the entire database
// stats - prints database statistics
// sstables - print sstable info
// heapprofile - dump heap profile (if supported by this port)
Instructions
Instructions taken from https://github.com/facebook/rocksdb/wiki/Benchmarking-tools
./db_bench --benchmarks=“fillseq”
./db_bench --benchmarks=“fillseq,stats” --statistics
./db_bench --benchmarks=“readrandom” --use_existing_db
./db_bench --benchmarks=“fillseq,readrandom,readseq”
RocksDB Benchmarks List:
readwhilewriting – 1 writer, N threads doing random reads
readwhilemerging -- 1 merger, N threads doing random reads
readrandomwriterandom -- N threads doing random-read, random-write
cache_bench
./cache_bench --help
cache_bench: Warning: SetUsageMessage() never called
…