Cache Benchmarks
10 comments
·July 11, 2025junon
nchmy
I wouldn't have even noticed if I hadn't seen this comment. Definitely necessary to change to linear scale.
Also, while I appreciate the thoroughness, I think it would be very useful to reduce the number of graphs significantly. Maybe 10x fewer. Just present the key ones that tell the story, and put the rest in another folder.
robinhoodexe
Agreed, it'd be nice to see the graphs with a linear scale.
magnio
Anyone knows how Garnet outperforms others so much in pipelining >1 tests while being written in C#?
greatgib
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.
dilyevsky
I assume because valkey is multithreaded and redis isn’t
motorest
I'm happy to see Valkey consistently outperforming Redis. It should be food for thought for anyone considering rug pulls.
phoronixrly
> c8g.8xlarge (32 core non-NUMA ARM64)
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...
swiftcoder
> a plateau is hit after 8 threads?
Most of the graphs plateau around 6 threads, for pretty much all the caches under test. I wonder if there is some interesting architectural issue with cache-sharing on this particular platform?
randomtoast
I would also like to see linear scaling graphs.
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.