Hello, your reasoning is what resulted in memcached to use a multi thread approach I guess. I don't agree with this design choice for a few reasons: in Redis we

Hello, your reasoning is what resulted in memcached to use a multi thread approach I guess. I don't agree with this design choice for a few reasons: in Redis we saw that multi gets are everything but a very used primitive. You can still group things that are often asked very often together, so that they'll be in the same instance (we have an explicit concept about this, called hash tags). We have hashes for objects that are composed of many fields, and it's a single key, so every kind of hashing algorithm will still lead to the object being stored together. In contrast see the benefits of a single threaded approach: zero contention, you can manipulate complex data structures without locking, more stability (less bugs) for the same amount of features. In my opinion it's a no brainer... but it's also a matter of taste / vision / priorities. About benchmarking with a multi threaded tool, this is something I'm going to investigate today because something is strange here. Let's assume that a multiplexing benchmark is not enough, why it was still able to saturate Redis better than memcached? I don't have a good answer to this question but I want to understand what's happening. Also, running multi-thread benchmarks against multi threads servers is going to bring results that are much different than what you'll get in the real world where there is a networking link between: when both the benchmark and the server thread are in the same core I think what happens is that the I/O system calls start to be much faster. It's a shame I don't have the hardware to perform the two boxes test as this could be really cool for Redis and memcached, a much better indicator of what the limits are currently with this two systems and in general with TCP servers.