Clarifications about Redis and Memcached • Hacker News Board

Re: Clarifications about Redis and Memcached

#41

Post by itamarhaber » Sun, Sep 27, 2015, 7:00 AM UTC

antirez wrote: post #32

yuliyp wrote: post #10

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

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 R…

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

Re: Clarifications about Redis and Memcached

#42

Post by mperham » Mon, Sep 28, 2015, 4:39 PM UTC

thezilch wrote: post #24

rubiquity wrote: post #23

I would guess that Mike Perham's point of view is based on how Sidekiq uses Redis for persisting jobs. If you don't configure Redis properly and you use Redis as a job queue as well as a cache then you risk the problem of your job queue entries getting evicted depending on your Redis config/version of Redis you are using. That type of thing happening frequently would be very annoying for someone that made a job queue…

That makes zero sense. Why would you run them out of the same instance / with the same configuration? Mike is already running a second process for caching; he'd simply replace it with a different instance of Redis.

Because users don't read docs. They don't understand these tools. They don't catch on that two completely different use cases require two completely different configurations and two completely different instances of Redis.

Re: Clarifications about Redis and Memcached

#43

Post by patsplat » Fri, Oct 02, 2015, 6:26 PM UTC

yuliyp wrote: post #26

patsplat wrote: post #11

Earlier quoted context omitted.

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

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?

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.