The choice for log graphs here probably wasn't necessary and seems to have hurt more than it helped. Despite looking relatively similar, memcached performed 3x faster than redis on some benchmarks whilst appearing only slightly above average.
Otherwise, very thorough and well done benchmark from the looks of it. Redis my beloved not holding up so well against some others these days it looks like.
Thanks for the feedback.
I updated the graphs to use linear scale by default. Log scale is still available, which is useful for latency viewing. Also only included the summarized graphs on the README. All graphs are moved into a separate file.
Does anyone have an idea about why there is such a gap sometimes between valley and Redis? I would have expected only a marginal différence at this point.
Why so? Just after the forking process Valkey has gone beyond what Redis is capable of due to high volumes of funding and new attention from devs wanting to improve Redis's performance.
If you look at Garnet's source code it is very non-idiomatic C#. It goes to extraordinary lengths to avoid the garbage collector. Almost all memory management is done with unmanaged memory and pointers.
They also have a very clever internal design and do some other tricks like strategically avoiding async/await and moving I/O operations onto the network request thread.
Be good to also include AWS own hosted variants of Elasticache. They do a bunch of tuning as well so the results are likely different vs running the same software on the same Aws instance type too.
I'm sad to see memcached is used with the legacy text protocol instead of the recommended (and supported by the benchmarking software) binary protocol.
That shouldn't be representative of any modern deployments and not even declaring this outside of the code itself is IMO misleading.
Please fix the documentation or better, run that one and update the graphs.
14 comments
[ 3.1 ms ] story [ 44.8 ms ] threadOtherwise, very thorough and well done benchmark from the looks of it. Redis my beloved not holding up so well against some others these days it looks like.
Requests are scheduled on half of these. Despite that, a plateau is hit after 8 threads? Is this a 16-core 32-thread type of a setup?
Also, consider redoing this in linear scale.
Edit: Oddly enough, no? 1 thread per core as per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-opti...
They also have a very clever internal design and do some other tricks like strategically avoiding async/await and moving I/O operations onto the network request thread.
That shouldn't be representative of any modern deployments and not even declaring this outside of the code itself is IMO misleading.
Please fix the documentation or better, run that one and update the graphs.