4 ms·
| Metric | DiceDB | Redis | | -------------------- | -------- | -------- | | Throughput (ops/sec) | 15655 | 12267 | | GET p50 (ms
by alexey-salmin 2y ago
| Metric | DiceDB | Redis |
| -------------------- | -------- | -------- |
| Throughput (ops/sec) | 15655 | 12267 |
| GET p50 (ms) | 0.227327 | 0.270335 |
| GET p90 (ms) | 0.337919 | 0.329727 |
| SET p50 (ms) | 0.230399 | 0.272383 |
| SET p90 (ms) | 0.339967 | 0.331775 |
UPD Nevermind, I didn't have my eyes open. Sorry for the confusion.
Something I still fail to understand is where you can actually spend 20ms while answering a GET request in a RAM keyvalue storage (unless you implement it in Java).
I never gained much experience with existing opensource implementations, but when I was building proprietary solutions at my previous workplace, the in-memory response time was measured in tens-hundreds of microseconds. The lower bound of latency is mostly defined by syscalls so using io_uring should in theory result in even better timings, even though I never got to try it in production.
If you read from nvme AND also do the erasure-recovery across 6 nodes (lrc-12-2-2) then yes, you got into tens of milliseconds. But seeing these numbers for a single node RAM DB just doesn't make sense and I'm surprised everyone treats them as normal.
Does anyone has experience with low-latency high-throughput opensource keyvalue storages? Any specific implementation to recommend?
- davekeck 2y ago> Something I still fail to understand is where you can actually spend 20ms Aren’t these numbers .2 ms, ie 200 microseconds?
- Kerbonut 2y agoLooks like your units are in ms, so 0.20 ms.
- alexey-salmin 2y agooh thank you, it's just me being blind
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- esafak 2y agoThey also sounded fishy to me. I'd expect closer to 10x as much throughput with Redis: https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/benchmarks/ https://redis.io/docs/latest/operate/oss_and_stack/managemen...
- bitlad 2y agoI think it is fishy based on this - https://dzone.com/articles/performance-and-scalability-analysis-of-redis-memcached https://dzone.com/articles/performance-and-scalability-analy...
- ajnin 2y agoI had the same reaction as you. And that's for 4 simultaneous clients, too, for a single client you get 3159 ops/s (from https://dicedb.io/benchmarks/ https://dicedb.io/benchmarks/). I'm not too familiar with in-memory databases in general but I would have expected figures in the millions on modern hardware. Makes me feel there's some hidden bottleneck somewhere and the benchmarks are not purely measuring the performance of the software.