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?

  • Drupal 6 or 7? What cache backend are you using? database, memcache? Varnish in front?
    – mikeytown2
    Commented May 1, 2012 at 1:16
  • 7 with memcache and Varnish
    – uwe
    Commented May 1, 2012 at 3:00
  • 1
    do i get it right that you mainly want to precache the views, not entire pages ?
    – mojzis
    Commented May 3, 2012 at 10:36
  • precaching views would be a great start.
    – uwe
    Commented May 24, 2012 at 17:28

5 Answers 5


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

  • Thanks. So this would be similar to using wget or curl to fetch a page in order to get it cached? If so, I'm unsure on how I would time it with the expiration of a cache.
    – uwe
    Commented Apr 24, 2012 at 14:42

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.


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.


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.


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.

  • 1
    While ESI is a good alternative to full page cache, the OP ask for a solution to warm the page cache up. Not for alternative caching solutions. Commented Sep 17, 2013 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.