3 ms·

It depends on many factors: whether content changes on a per-user basis, what you're caching, how volatile the data is, what the expiration strategy is, how man

by patio11 12y ago

It depends on many factors: whether content changes on a per-user basis, what you're caching, how volatile the data is, what the expiration strategy is, how many separate app servers you have, etc. If you're caching publicly viewable pages which change infrequently, you should probably be using either page caching (if you have one or a small number of app servers) or a caching proxy like e.g. Varnish. If you're caching intermediate calculations which are very volatile, Memached is a great choice. If you're caching intermediate calculations which should be persisted for arbitrarily long periods of time, Redis is a great choice. I personally use a combination of memcached and Redis for most of my Rails projects. Rails.cache is the memcached instance but I keep a ModelObject.cache instance around which encapsulates a Redis instance but conforms to the general CacheStore contract with regards to read, write, and fetch semantics.

cat9 12y ago
I think Memcached is currently better in some specific cluster scenarios, which would hopefully be researched in more depth than "Ask HN" before planning. Otherwise, anything you can do with Memcached, you can do with Redis, but without keys arbitrarily falling out the bottom. Also unless you're bigger than StackOverflow, most of those scenarios can be solved by "throw more RAM in it." Memcached isn't bad or anything like that. There are many algorithms where "let old stuff fall off the page" is perfectly healthy. I just don't see a need to use both, and I prefer explicitly designed expiry behavior vs. letting stuff fall out of memory, and I find Redis easier to work with. $0.02, YMMV. If your engineers are used to working with both, having both available costs way less than making them do mental gymnastics to get around not having it, although that might take itself out in onboarding time or code complexity or whatever. But mostly not, if you have good interfaces set up like Patrick. P.S. - Don't put sessions in Memcached, ever. Having users sessions die randomly because you used too much RAM is terrible design. Putting them in Redis is fine, in which case you probably want to set an expires property when they're created & update it when they're read. Or issue a rename if you're doing one-request-per-key, whichever.

by patio11 12y ago

cat9 12y ago

I think Memcached is currently better in some specific cluster scenarios, which would hopefully be researched in more depth than "Ask HN" before planning. Otherwise, anything you can do with Memcached, you can do with Redis, but without keys arbitrarily falling out the bottom. Also unless you're bigger than StackOverflow, most of those scenarios can be solved by "throw more RAM in it." Memcached isn't bad or anything like that. There are many algorithms where "let old stuff fall off the page" is perfectly healthy. I just don't see a need to use both, and I prefer explicitly designed expiry behavior vs. letting stuff fall out of memory, and I find Redis easier to work with. $0.02, YMMV. If your engineers are used to working with both, having both available costs way less than making them do mental gymnastics to get around not having it, although that might take itself out in onboarding time or code complexity or whatever. But mostly not, if you have good interfaces set up like Patrick. P.S. - Don't put sessions in Memcached, ever. Having users sessions die randomly because you used too much RAM is terrible design. Putting them in Redis is fine, in which case you probably want to set an expires property when they're created & update it when they're read. Or issue a rename if you're doing one-request-per-key, whichever.