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 f

Answer 1

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

Answer 2

If your design calls for a write-through cache, you still have an issue with coming up against the memory limit allocated to memcached which is where LRU comes into play.

LRU has two rules when determining what to kick out, and does so in the following order:

1. Expired slabs
2. Oldest unused slab

Providing different expiration dates for different groups of objects can help keep less-frequently accessed data that is more expensive to cache in memory while allowing more frequently used slabs that might still find their way to the end of the queue, but are easy to recreate, to expire.

It is also the case that many cache keys wind up becoming aggregates of other objects, and unless you employ a lookup hash for those objects, it's much easier to just let the objects expire after a few hours than to proactively update all the associated keys, and it also preserves the hit/miss ratio that you are effectively vying for by using memcached in the first place.

Answer 3

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 4

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 5

Some data in cache is expensive to create but small (should last a long time) and some is large but relatively cheap (should last a shorter time)

Also, for most applications it is hard to make memcached work as a write through cache. It is difficult to properly invalidate all caches, especially those of rendered pages. Most users will miss a couple.

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.