Anyone interested in memcached protocol?

[Magnus Hagander]

On Tue, Jun 15, 2010 at 00:34, Adrian Otto <aotto at mosso.com> wrote:
> 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

Just as a point, isn't this a lot simpler to do with just a trigger on
the table firing off a regular purge request to varnish? No need for
replication or an extra watcher daemon or anything like that. I guess
it could be a problem if varnish is slow to respond, but really,
varnish has never been slow to respond in any of the cases I've done
it :-) And even with a deamon, using a trigger ought to be much
easier, no?

(Granted, I've not done this on MySQL specificall, only PostgreSQL,
but since it has triggers by now, I don't see why it wouldn't work)


> 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.

Shouldn't grace-mode be able to handle this? Granted it will get the
old content until the refresh has finished, but other than that? (And
we're talking asynchronous changes anyway, so that shouldn't make a
huge difference)


> 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

If it's ok to serve stale content while it's reloaded, grace should do
it, I think, no need for the custom stuff.

If it's not ok, then I think you need to do a distributed transaction
with the database, which is way beyond anything varnish can (or
should!) do.

Or am I missing something? :-)


> Actually using varnish directly as an object cache is another use case that
> seems equally compelling.

But we already have memcached for that, no? Why do we need another
product to do it?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/