[antirez]

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.

[vitalyd]

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.

[natebrennand]

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...

[acconsta]

Already exists for memcached!

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