[yuliyp]

For a post that attempts to compare Redis to memcached for caching, it's amazing how few actual numbers appear in the post.

[antirez]

Hello, it's a shame I was not able to provide numbers. I did in the past, and went to the point of porting redis-benchmark to memcached in order to test it in a very similar fashion, but now the code is deprecated and I've no easy way to test it again. From what I saw back then, the difference "per core" is not going to be big either side. I remember Redis was faster in my tests per single core, but after that both Redis and Memcached got many optimizations, so now it can be the other way around. But I doubt to spot huge differences. Yet... it's worth to try and maybe Redis Labs memtier_benchmark may be helpful here: https://redislabs.com/blog/memtier_benchmark-a-high-throughp.... Soon or later I'll try again, this may be very useful to spot inefficiencies in both sides.

[itamarhaber]

I took the liberty of doing a very naive test on my laptop's VM - the results are at https://gist.github.com/itamarhaber/2ed09513ec6f6ae10071.

  Memcached text: 43585 OPS @ 4.58 msec 
  Memcached binary: 40242 OPS @ 4.96 msec
  Redis: 39727 OPS @ 5.03 msec
  Redis, pipeline 4: 131312 OPS @ 6.09 msec

[patsplat]

"Actual numbers" for caching services only have meaning in the context of a particular application.

[yuliyp]

Yes, but as-is the post is pure hand-waving. At least some measurement could confirm the theories being stated. Did someone actually try taking one use case where they had memcached and replace it with Redis? What actually happened?

[patsplat]

Ok then. Build an application heavily dependent on caching. Restart memcached in the middle a production workload. How long does it take to get out from under the dog pile?

EDIT: This started out a bit flippant. Wanted to make the point that antirez is not just handwaving.

For example one of the points without elaboration was 'there are “pure caching” use cases where persistence and replication are important'. Sometimes caching warming isn't feasible i.e. needing to restart the cache in the middle of a production workload. Using entirely volatile cache one can find extended downtime from the dog pile of requests waiting for the cache to warm up. Persistence can be an attractive form of insurance against this scenario.

[forgotpwtomain]

Unless it was some very limiting case, I doubt there was much of a difference -- for simple operations e.g. REDIS (GET/SET) the IPC/network stack will contribute more the to the runtime than the difference between the choice of caching programs.

[antirez]

Exactly, basically we can provide numbers only for GET/SET/DEL or similar workloads. Since Redis has more capabilities that may speedup dramatically certain use cases the only good comparison would be per-use-case. However to provide the basic operations benchmarks for different data sizes can give at least an idea about the "HTML fragments caching" use case and other similar workloads.