How to rebuild a cached page when it expires?

Question

I'm using views caching after reading this great Q&A and getting good results. I have to keep the expiration short because I'm showing the "last comment" in the view and those changes often.

I'm thinking about using views content cache to expire the cache every time a comment is added. Or cache actions to do it with rules.

What I would like to do is rebuild the cache immediately after it expires? I read that boost module offers that but I need a solution for authenticated visitors (already use Varnish for anonymous).

The cache graceful module seems to offer that but only has 20 installs (plus requires a couple of other modules).

Are there any other solutions that allow expiring a cache and "warming" it up right away?

Answer 1

If you know what functions need to run in order to warm a cache, checkout httprl. httprl_queue_background_callback() is the function to look into using. Simple example of calling watchdog in the background http://drupalcode.org/project/httprl.git/blob/24a88acd2180191d0b54696e577f14615e37302d:/README.txt#l268

In terms of graceful varnish cache clears this has a good example: https://www.varnish-cache.org/trac/wiki/VCLExampleGrace Example of it in use: http://groups.drupal.org/node/63203

Answer 2

Boost for Drupal 7 works admirably well and, thanks to its new Crawler submodule and the Cache Expiration module, you can conditionally expire and proactively re-cache any selection of your pages. With a setup like this you do not need modules such as Views Content Cache because you can achieve the same behaviour with the above concoction, and not just for views (Cache Expiration integrates with Rules, so possibilities are really endless). There is a full recipe to get this working at this page.

Answer 3

There is a rather new Module which is called https://www.drupal.org/project/recacher It works together with https://www.drupal.org/project/expire and https://www.drupal.org/project/httprl_spider

Instead of re-crawling everything it only re-caches the nodes that have been exipred bei the expires Module.

In my landscape it should work like that: On Node Change / Create -> Expire -> Purge from Nginx -> re-Cache with httprl_spider.

That way the cache will be fresh in most cases.

Answer 4

You should consider using cache actions module in conjunction with a custom module that can reuse the code from cache warmer module.

Cache warming can be done by pinging the changed/desired urls as various users(One user per rule). You would need to make some cURL calls along with the user credentials. Cache Warmer module has the code for how this calls should be made.

So using Caching Actions module you can say when the cache for a particular page should be broken and in the subsequent action in the you could call the function from your custom module for cache-warming that particular url or set of urls.

Answer 5

I think that your best option is Edge Side Includes. Take a look at the Edge Side Includes integration module. Here is a quote about it (from the module's project page):

ESI - or Edge Side Includes - is a high performance caching solution for Authenticated users but can be helpful for Anonymous users as well.

Typically, pages which are personalised for authenticated users (even minor personalisations, such as a block which says "Logged in as manarth") will prevent reverse-proxies (which can easily perform 100 times faster than Drupal) from caching the page, because messages intended for one user could then be seen by another.

ESI is a W3C standard to address this issue. The personalised content is replaced with an ESI tag - <esi:include src="http://example.com/esi/block/xxxxxx" /> - which is identical for every user; the page can then be cached. Edge devices such as Varnish fetch the ESI URL, and merge its contents with the cached page (and the contents of that ESI URL may also be cached).

This technique can easily improve performance by 10x, 100x, maybe even more.