<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Varnish Devs,<div><br></div><div>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.</div><div><br></div><div>Imagine this example of a database driven web site accelerated with Varnish:</div><div><br></div><div>Web Client -> Varnish -> Apache LAMP APP -> MySQL.</div><div><br></div><div><b>Basic Setup</b></div><div><br></div><div>1.1) Page is accessed by web client, and HTML generated by the app as the result of a MySQL query.</div><div>1.2) Cached content used until TTL reached.</div><div>1.3) Clients accessing expired pages repeat the procedure at step 1.1.</div><div><br></div><div><b>Basic Setup + Auto-Purge</b></div><div><br></div><div><div>2.1) Page is accessed by web client, and HTML generated by the app as the result of a MySQL query.</div><div>2.2) Clients use cached content until TTL reached, or until content is purged.</div><div>2.3) Row changes in MySQL database, triggering blackhole storage engine on a replica database, replication log acted upon by watcher daemon.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>New Setup with memcached Protocol Integration</b></div><div><br></div><div><div><div>3.1) Page is accessed by web client, and HTML generated by the app as the result of a MySQL query.</div><div>3.2) Clients use cached content until TTL expires.</div><div>3.3) Row changes in MySQL database, triggering blackhole engine on replica database, replication log acted upon by watcher daemon.</div><div>3.4) Watcher daemon performs a CAS operation to swap in a fresh version of the cached content.</div></div></div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>My question is if <b>anyone else</b> 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.</div><div><br></div><div>Thanks,</div><div><br></div><div>Adrian Otto</div></body></html>