Re:Segcache: A memory-efficient and scalable key-value cache...
by 1a1a11a on Thursday April 15, 2021 @07:07PM
(#26827312)
I might be dumb about estimating throughput.
According to https://github.com/Cyan4973/xxHash, the best hash function can only do 100s M hashes per second, how can a local cache run at such throughput? I assume when measuring cache throughput, one need to calculate hash, look up, (maybe compare keys), and copy the data.
[ Parent
| on HN ]
Re:Segcache: A memory-efficient and scalable key-value cache...
by NovaX on Thursday April 15, 2021 @07:13PM
(#26827352)
Are you comparing a single threaded hash benchmark to a multithreaded cache benchmark? An unbounded concurrent hash table has 1B reads/s on a 16 core machine (~60M ops/s per thread)
Re:Segcache: A memory-efficient and scalable key-value cache...
by 1a1a11a on Friday April 16, 2021 @10:06PM
(#26841048)
Oh, my bad, thank you for pointing out! BTW, just for my curiosity, where is the 1B reads/s benchmark?
Re:Segcache: A memory-efficient and scalable key-value cache...
by NovaX on Saturday April 17, 2021 @04:20AM
(#26842555)
A multi-threaded benchmark of a cache should be fully populated and use a scrambled Zipfian distribution. This emulates hot/cold entries and highlights the areas of contention (locks, CASes, etc). A lock-free read benefits thanks to cpu cache efficiency causing super linear growth.
This shows if the implementation could be a bottleneck and scales well enough, after which the hit rate and other factors are more important than raw throughput. I would rather sacrifice a few nanos on a read than suffer much lower hit rates or have long pauses on a write due to eviction inefficiencies.
[1] https://github.com/ben-manes/caffeine/wiki/Benchmarks#read-1...
[2] https://github.com/ben-manes/caffeine/blob/master/caffeine/s...