memcached as a level 2 cache

[Erik Mogensen]

Hi!

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.

For example:

   touch <key>*\r\n


Possibly with a response mimicking the "get" command:

   PRESENT <key> <flags>\r\n
   END\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...
-- 
-mogsie-