Anyone interested in memcached protocol?

[Adrian Otto]

Varnish Devs,

In considering the recent question from Joe Chen (Re: Preloading  
Cached Contents into Varnish?) it renewed an interest of mine to put a  
memcached client API interface on Varnish. There is code in the  
libmemcahced project that should streamline the implementation from  
the protocol perspective. This way any memcached client could operate  
on the contents of the Varnish cache, which could be used as a push  
update mechanism. With SASL auth implemented, this could be done  
securely. I recognize that there are ways to accomplish this with  
memcached using VM and simply allowing it to swap, or using the  
storage engine interface with a persistence engine on the back. I'd  
like to have the flexibility to use a varnish cluster as both a web  
cache and an object cache. This has large potential benefits from an  
operational perspective, where we'd like to keep the number of servers  
in a given configuration to a minimum. It also opens up new  
possibilities where a memcached client can act upon the contents of  
the cache in cases where web clients are the target consumers of the  
content.

Imagine this example of a database driven web site accelerated with  
Varnish:

Web Client -> Varnish -> Apache LAMP APP -> MySQL.

Basic Setup

1.1) Page is accessed by web client, and HTML generated by the app as  
the result of a MySQL query.
1.2) Cached content used until TTL reached.
1.3) Clients accessing expired pages repeat the procedure at step 1.1.

Basic Setup + Auto-Purge

2.1) Page is accessed by web client, and HTML generated by the app as  
the result of a MySQL query.
2.2) Clients use cached content until TTL reached, or until content is  
purged.
2.3) Row changes in MySQL database, triggering blackhole storage  
engine on a replica database, replication log acted upon by watcher  
daemon.
2.4) Watcher daemon expires the cached page asynchronously, and re- 
requests it to re-cache it. If not already cached, does not re-load it.

The advantage here is faster convergence of the cached content and the  
database contents. This setup has a problem because there is a  
possible race in 2.4 between expiring the content, and re-caching it.  
It's possible for the client to get forwarded all the way to the back- 
end and wait for the application to regenerate the content, rather  
than always getting a cached version. This is especially true if  
generating the content takes a long time, and/or if the object is  
constantly being accessed.

New Setup with memcached Protocol Integration

3.1) Page is accessed by web client, and HTML generated by the app as  
the result of a MySQL query.
3.2) Clients use cached content until TTL expires.
3.3) Row changes in MySQL database, triggering blackhole engine on  
replica database, replication log acted upon by watcher daemon.
3.4) Watcher daemon performs a CAS operation to swap in a fresh  
version of the cached content.

The advantage is that the race in 2.4 is eliminated in 3.4 because the  
replacement was both asynchronous and atomic. Clients always get a  
cached result for content that has not expired or been evicted from  
the cache.

You might argue that having a CAS purge feature in varnish might be  
equally helpful for this use case. I'm simply trying to illustrate one  
possible integration where the additional protocol availability would  
be useful. Actually using varnish directly as an object cache is  
another use case that seems equally compelling.

My question is if anyone else has a use case for this capability, and  
would you have an interest in having this added as a new feature? If  
so, I may be willing to contribute.

Thanks,

Adrian Otto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.varnish-cache.org/pipermail/varnish-dev/attachments/20100614/33e214ba/attachment-0001.html>