Sled: Extremely slow vs Rocksdb

[pakipaki2000]

Hi,

I wanted to try Sled but I don't understand the insane performance differences:

for i in 0..100000 {
    db.put(b"my key", b"lol");
}

167ms (rocksdb)

Same but with Sled leads to 448ms, almost 3 times slower.

I've tried tweaking config such as:
let config = pagecache::ConfigBuilder::default()
.path("/dev/shm/db".to_owned())
.cache_capacity(10_000_000_000)
.use_compression(false)
.flush_every_ms(Some(1000))
.snapshot_after_ops(100_000_000).temporary(true).build();

But I only gain a few ms...

Machine is 32 cores 128GBRAM...
How to reach Rocksdb performances with Sled?

[spacejam]

Most tuning efforts have gone into sustained reads and writes on larger datasets than 1 key. 100000 operations does not give the system much of a chance to warm up. Sled quickly sets up a tree structure with the assumption that there will be hundreds of thousands to billions+ of keys and values, which might penalize the first few seconds of the system's lifetime as more work is spend growing + splitting the initial tree nodes as it goes from 1 index node and 1 leaf node to several levels deep.

One real issue you may be hitting is that I haven't spent much time trying to tune counter-like workloads where a single key is being hammered. In general, the writepath still has some major optimizations left to do, and the readpath is where more time has been spent.

If you provide information about a real workload, I can give you more valuable information. You might find more favorable comparisons to RocksDB with read-heavy workloads, and mixed workloads that hit more than 1 key.

In the future, including the SVG output of this tool will also help me pinpoint specific performance issues you may be hitting: cargo flamegraph.