Performance stats for in-memory
Jonty opened this issue · comments
It looks like you're benchmarking redis against redka when redka is using a disk-backed sqlite - this isn't really a fair comparison as redis doesn't synchronously write changes to disk and sqlite does. Redis operates entirely in memory and persists to disk by forking the process periodically, then the fork writes out the contents of its memory to disk so it doesn't impact the main process.
It would be interesting to compare the performance of redis with persistance disabled and redka using an in-memory SQLite, just to see what the core performance of the engine actually is when operating with the same guarantees as redis.
On my laptop, running redka with: build/redka -p 6380 :memory: increases speed quite a bit.
In-memory build/redka -p 6380 :memory::
$ redis-benchmark -p 6380 -q -c 10 -n 1000000 -r 10000 -t get,set
WARNING: Could not fetch server CONFIG
SET: 30426.58 requests per second, p50=0.255 msec
GET: 63812.14 requests per second, p50=0.103 msec
build/redka -p 6380 /tmp/deleteme.db:
$ redis-benchmark -p 6380 -q -c 10 -n 1000000 -r 10000 -t get,set
WARNING: Could not fetch server CONFIG
SET: 21631.91 requests per second, p50=0.343 msec
GET: 56734.37 requests per second, p50=0.119 msec
(MacBookPro18,4, 10-core M1 Max, running on battery with no attention paid to background processes or anything fancy like that)
As far as I can tell it's using WAL mode with pragma synchronous = normal;, which doesn't flush writes to disk immediately. That's why you see such high write performance even when using persistent mode: https://github.com/nalgeon/redka/blob/main/internal/sqlx/db.go
Fair enough. I've added the in-memory test results to the Performance section.