memcached expiration time

Question

Memcached provides a cache expiration time option, which specifies how long objects are retained in the cache. Assuming all writes are through the cache I fail to understand why one would ever want to remove an object from the cache. In other words, if all write operations update the cache before the DB, then the cache can never contain a stale object, so why remove it?

One possible argument is that the cache will grow indefinitely if objects are never removed, but memcached allows you to specify a maximum size. Once this size is reached, memcached uses a least-recently-used (LRU) algorithm to determine which items to remove. To summarise, if a sensible maximum size has been configured, and all writes are through the cache, why would you want to expire objects after a certain length of time?

Thanks, Don

Answer 1

There are several reasons:

1. Data storage is not persistent between server restarts. You will have to regenerate a large cache data after you restart or reload a caching server.
2. There might be cases when you are not notified when an object has updated. eg. User details returned by APIs.
3. Searching an object. SQL provides using same data to generate different results depending on requirements like recent and most-voted etc. You will have to use different cache keys to store the data for such different results (data duplication, a headache to update all relevant keys even if a single common datum changes). Also with Database Server you have greater flexibility on skimming through the data (custom stats, etc).

Answer 2

Expiration times are useful when you don't need precise information, you just want it to be accurate to within a certain time. So you cache your data for (say) five minutes. When the data is needed, check the cache. If it's there, use it. If not (because it expired), then go and compute the value anew.

Some cached values are based on a large set of data, and invalidating the cache or writing new values to it is impractical. This is often true of summary data, or data computed from a large set of original data.

Answer 3

We have been thinking about the same and this is what is on memcached wiki "Even if you're actively deleting or overwriting cached data, you'll still want to have the cache expire occasionally. In case your app has a bug, a crash, a network blip, or some other issue where the cache could become out of sync."

This makes sense as we cannot plan for network blips and it becomes important if we are releasing code every day or 2 or week. one thought we have is to restart memcached server every release, but that will get really painful if there are 10 or more memcached servers. The simplest thing I believe is to set expiry on objects.

Answer 4

One case would be where a value is only valid for a certain period of time.

Answer 5

I was curious about this myself, when I first started working with memcached. We asked friends who worked at hi5 and facebook (both heavy users of memcached).

They both said that they generally use something like a 3 hour default expire time as sort of a "just in case".

1. For most objects, it's not that expensive to rebuild them every 3 hours
2. On the off chance you've got some bug that causes things to stay cached that shouldn't otherwise, this can keep you from getting into too much trouble

So I guess the answer to the question "Why?" is really, "Why not?". It doesn't cost you much to have an expiration in there, and it will probably only help ensure you're not keeping stale data in the cache.

Answer 6

I'd say it is about the distinction between 'Least Recently Used' and 'Not Gonna Be Used Anymore' ... if you can indicate explicitly which objects can be taken out of the cache, that leaves more room for objects that may still be used later.