Hacker News Reader

Comment by devit | Hacker News Reader

If data access is equally distributed across keys, then running multiple Redis instances (with sharding) is perfect, since ultimately you want each key to be serviced by a single core, for optimal performance in a system with caches and NUMAs.

However, if data access is read-heavy and not equally distributed across keys, then having shared memory (aka multithreading) is quite essential since you want all cores to operate on the same data, and shared memory is much better than sending the data across especially if the heavily accessed keys vary quickly over time.

I'm not sure if memcached handles this well (it requires a lightweight rwlock/RCU/MVCC mechanism, for instance), but a shared-nothing system like Redis cannot provide good performance in all cases.

View on HN

In a networked server getting data from memory, the time required to access the data itself is negligible, so the real performance in mostly a factor of how much I/O a thread can sustain (Redis with heavy pipelining will handle at least 500k ops/sec in the same hardware it handles 100k ops/sec without pipelining). There is still the case of the load to be very biased towards, like, 5% of keys. But that 5% of keys are very very likely to be distributed across all processes.

However this is not true when you have a case with, like, 2/3 super hot keys that are requested a lot more than any other. But in this case what allows scalability is replication with many read-replicas.

I think once you implement threaded i/o, requests for hot keys will hit in the cpu cache and you'll become NIC limited. At that point, read replicas is the best solution rather than shared memory since contention will move to NIC and adding more cpus won't help.

Edit: Salvatore, you should also look at the Seastar/ScyllaDB design (if you haven't yet) - that architecture would work well for redis as well. And if user has access to DPDK (or other kernel bypass enabled NICs, like Solarflare), their performance will go up even further.

The group behind Arrakis did some testing by bypassing the kernel through NIC's and the results were pretty amazing. They also made modifications to memcached and got similarly great results FWIW.

https://www.usenix.org/system/files/conference/osdi14/osdi14...

Already exists for memcached!

https://github.com/scylladb/seastar/wiki/Memcached-Benchmark

Good point, but I could add that case 1 is vanishingly unlikely to happen in a real system. You always have hot keys, i.e. a Zipfian distribution. That's almost tautological for a cache -- by using a small amount of space you can handle most of the reads.

So, not knowing much about Redis, I would conclude based on this blog post that memcached has a pretty big advantage as a cache in real systems (multithreading).

I think this is not the case, I already replied to the parent comment.

Reply on news.ycombinator.com