memcached as a level 2 cache
mogsie at escenic.com
Wed Oct 13 04:53:14 PDT 2004
I'm thinking about using memcached for a second level cache, but it
poses a few problems. We've looked at the 'demographics' of our caches,
and we've seen a few very popular objects, and a lot of objects which
aren't used that often, and a third set of objects which are accessed
once, and almost never again. Each of these three groups take up
roughly the same amount of space.
If we replaced our own in-process cache with memcached, then all would
be fine and dandy, but we would be hitting the cache too often; most of
the time, several hits per request (due to the architecture of the
application). Because of this, I would like to have a small in-memory
cache which would be the primary cache (level 1) and delegate memcached
to a secondary (level 2) cache.
The problem with such a setup is that I have no way of informing the
memcached that an object was hit in the level 1 cache, other than by
actually GETting it -- this defeats the purpose. What I'm looking for
is a new command which is _almost_ the same as a GET, except that it
doesn't actually return anything.
Possibly with a response mimicking the "get" command:
PRESENT <key> <flags>\r\n
The only thing that the server needs to do is to update the "last
retrieved date" or similar.
This way, the LRU algorithm of the second level cache would reflect the
popularity of objects in the L1 cache.
It is also a good protocol expansion if anyone wanted to create a
memcached-proxy; for example, a proxying memcached which could
transparently implement RAID-type redundancy, or support hot-plugging of
memcached servers. No-one in their right mind would do so, however, as
it would be a huge single point of failure...
More information about the memcached