Ask HN: Ruby cache solution | Hacker News Reader

Ask HN: Ruby cache solution

6 pointsMarkNowq6667 comments

Is it redis the best solution to caching rails app?

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.

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.

Redis isn't a cache, so no it is not the best solution for caching a Rails app. Keeping in mind that other tools you might use, such as background processors like Resque/Sidekiq, also use Redis you should definitely not be using Redis as a cache.

If your setup is simple (single node, few processes) and caching is minimal (just caching some things at boot time) you could get away using ActiveSupport's MemoryStore. Otherwise I recommend just setting up Memcached (it's dead simple).

I am wondering if Fragment Caching on File is good enough for a rails app with several K's visits per month?

I also wonder about this because the operating system maintains its own cache for frequently accessed files. Or even one could put the file cache on a ramdisk.

Looks like this has been asked before: http://serverfault.com/questions/624104/rails-filestore-with...

Memcached is better suited as an actual cache. Last time I looked if Memcached runs out of memory it purges old cache data. Not sure if Redis can be configured to do this.

Yes, there's a Redis eviction policy called `allkeys_random` that's basically the same thing.

Reply on news.ycombinator.com