Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clarifications about Redis and Memcached

antirez.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Clarifications about Redis and Memcached

#21

Post by vitalyd »

antirez wrote: post #19
devit wrote: post #12

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

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…

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.

Re: Clarifications about Redis and Memcached

#22

Post by LukaAl »

I tried both and i prefer Redis over Memcached except for very simple use cases. It is true that for a pure caching system Memcached is easier to setup, easier to scale and faster. But by just a small margin. On the opposite side, Redis provide a lot of primitive very fast and implemented in C that allow for more complex use cases. For instance, in one of the project I was following, the ability to merge two or more sorted set was pivotal in implementing a more efficient warm-up scheme. I could get the same result with Memcached and a software layer, but it would be less efficient in term of latency and bandwidth. Given these huge advantages, my choice is almost always Redis because I prefer to manage one system instead of two.

Re: Clarifications about Redis and Memcached

#23

Post by rubiquity »

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 uses Redis for persistence of jobs.

Caching web content can grow and grow until you run out of memory. If you aren't using Redis for data that can be easily regenerated, then go ahead and use Redis as a cache. But if you are, I think it will give you operational peace of mind to segregate where you store your background jobs and where you cache content.

Re: Clarifications about Redis and Memcached

#24

Post by thezilch »

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.

Re: Clarifications about Redis and Memcached

#25

Post by rubiquity »

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.

You're right. It doesn't make sense. Does that prevent tons of people from doing it? Nope.

Re: Clarifications about Redis and Memcached

#26

Post by yuliyp »

patsplat wrote: post #11
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.

"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?

Re: Clarifications about Redis and Memcached

#27

Post by natebrennand »

vitalyd wrote: post #21
antirez wrote: post #19

Earlier quoted context omitted.

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…

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…

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

Re: Clarifications about Redis and Memcached

#28

Post by forgotpwtomain »

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?

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.

Re: Clarifications about Redis and Memcached

#29

Post by NovaX »

antirez wrote: post #6
gtrubetskoy wrote: post #2

I'm curious about the "threaded redis" reference. Back a couple of years ago I built a Collaborative Filtering recommendation system that used Redis for graph storage and relied heavily on sorted sets to compute the recommendation right in Redis. I really needed some kind of a parallelism and so I hacked together http://thredis.org/ (and then mostly for fun added SQL operations to it by linking it with SQLite). Since…

I remember thredis very well! But it's different compared to what memcached does and Redis has plans for: memcached just threads the I/O part, not the access to the key space which is serialized via a mutex. However what you had in mind is also in our long term plans... and was addressed in another blog post here: http://antirez.com/news/93

The locks are becoming more fine-grained in memcached [1], so that should be less of a problem now.

It is possible to remove lock contention on the read path [2] if a concurrent hash table is used. This can be done while using an O(1) eviction policy that outperforms LRU [3].

[1] https://github.com/memcached/memcached/pull/97 [2] https://github.com/ben-manes/caffeine/wiki/Design [3] https://github.com/ben-manes/caffeine/wiki/Efficiency

Re: Clarifications about Redis and Memcached

#30

Post by antirez »

NovaX wrote: post #29
antirez wrote: post #6

Earlier quoted context omitted.

I remember thredis very well! But it's different compared to what memcached does and Redis has plans for: memcached just threads the I/O part, not the access to the key space which is serialized via a mutex. However what you had in mind is also in our long term plans... and was addressed in another blog post here: http://antirez.com/news/93

The locks are becoming more fine-grained in memcached [1], so that should be less of a problem now. It is possible to remove lock contention on the read path [2] if a concurrent hash table is used. This can be done while using an O(1) eviction policy that outperforms LRU [3]. [1] https://github.com/memcached/memcached/pull/97 [2] https://github.com/ben-manes/caffeine/wiki/Design [3] https://github.com/ben-manes/caffe…

NovaX: thanks for the interesting references. The point is, is it worth for memcached to avoid the global interpreter lock in the hash table with the number of cores currently deployed machines have? I would expect to see very little contention. The concurrent hash table looks a good idea for memcached, for sure to have a mutex per key would be likely an overkill in terms of memory usage. I'll try to read with care the links you provided, thank you.
Post reply on HN