1
votes

I want to use gem "redis-store" as cache store in my Rails app. Unlike memcached redis doesn't cleanup unused keys, but I can use EXPIRE command on each key (via :expire_in option) to limit lifetime of each key.

Then I want use cache_key of my model (which includes id and updated_at) as part of redis key, used for caching. So when model will be updated, new cache key will be created, and old one will never be used.

So the question is, which expiration time to choose? If set too small, it eliminates benefits from caching, if too long - it fills redis with unused data, which can (probably) reduce performance. Where is golden mean?

2
Cache expiration is one of the only two hard things in programming :)Sergio Tulentsev

2 Answers

1
votes

I would suggest to use the LRU expiration strategy of Redis to let Redis expire the least recently used keys itself. This way, you don't need to worry about the expiration of keys yourself.

Using the cache_key of your model as you suggested will indeed generate a new key when your model changes. The 'old' key(s) for that model will not be used anymore by your views, and Redis will expire them eventually.

See http://redis.io/topics/config for information how to configure Redis as a LRU store.

0
votes

Surely this is app dependent? If it's a really expensive page, you want it re-calculated as rarely as possible, but if it changes rapidly, you have no options.

I'd personally experiment. Pick some numbers and see how they affect performance. Err high to start with (trust your database, in this case Redis), and then tweak them if you have problems.