Mikkel Høgh

I hate to break it to you,

I hate to break it to you, but Varnish is not doing anything for you. By default, Varnish will not cache any object when the request contains a cookie. Since Drupal sets session cookies which are present for all requests to your server, Varnish isn't caching a thing. Also, because Drupal sets Expires headers in the past and Cache-Control headers, the most expensive thing you're serving as far as total CPU cycles, queries and I/O (pages generated by Drupal to anon visitors) won't be cached.

I've recently gone through the process of getting Drupal to play nice with Akamai, and the process for Varnish is very similar. To really make Varnish work, some hacking of bootstrap.inc, index.php, a custom module and changes to your Varnish configuration are required to take full advantage.

In index.php after $return = menu_execute_active_handler(); <?php global $user; if (!$user->uid && count(drupal_get_messages(NULL, FALSE)) != 0){ header("Expires: Sun, 19 Nov 1978 05:00:00 GMT"); header("Cache-Control: no-cache, no-store"); } ?> This will make sure that pages with messages served to anonymous users will not be cached, or you'd end up serving article pages to anon users with "Your comment has been queued...". Expires is set to Dries's birthday, as is default for Drupal.

On my site, I've disabled page cache, leaving anonymous caching to our cache (Akamai in my case) so all I have to worry about is drupal_page_header() in bootstrap.inc which now looks like this: <?php function drupal_page_header() { //header("Expires: Sun, 19 Nov 1978 05:00:00 GMT"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); //header("Cache-Control: store, no-cache, must-revalidate"); //header("Cache-Control: post-check=0, pre-check=0", FALSE); } ?>

If you're running Drupal 5, which doesn't have D6's ip_address() function, no host based access, poll voting, etc will work without some tweaks. I've added this function in bootstrap.inc, and added a call to it in drupalbootstrap() in the DRUPAL_BOOTSTRAP_CONFIGURATION case. replacing $_SERVER['REMOTE_ADDR'] is a bit of a hack, but is far easier than patching every occurrence of it in all of core with a function call.

[HTML_REMOVED]

The last bit of Drupal code is a module to set a cookie so that your cache/proxy can differentiate anonymous from logged in users. Both Akamai (with their advanced configuration package) and Varnish can pass traffic through to the origin and not cache it based on the presence of a cookie.

[HTML_REMOVED]

/ * Implementation of hook_user() * Set/unset nocache cookie on login/logout / function varnish_user($op, &$edit, &$account, $category = NULL){ switch($op){ case 'login': setcookie('nocache', 1, time()+31536000, '/'); break; case 'logout': setcookie('nocache', '', time()-31536000, '/'); break; } } ?>

Finally, you're going to need to tell Varnish to cache objects with cookies, except if it's the nocache cookie (unless the file extension is js, css, jpg, jpeg, gif, png, etc.). As I don't have any experience with Varnish's vcl configuration language, and the documentation seems a little sparse, I'll leave this up to you, but I have found a couple places to start: http://varnish.projects.linpro.no/wiki/VCLExampleCacheCookies http://wiki.developer.mindtouch.com/User:PeteE/Varnish_Installation

There, now Varnish is serving the most expensive portion of your requests, the parts generated by Drupal, and is also serving your js, css and images. You'll probably also want to set TTLs for the various bits you're serving - I've got images and flash at 7 days, css and js at 6 hours and pages at 10 minutes.

Ah, why can’t such things

Ah, why can't such things never be easy ;)

Well, at least Varnish was easy to configure, now we just need to fix Drupal. I may have an idea, but I'm going to post it at bug #147310 so that others may benefit as well :)