Small-scale caching improvementsΒΆ

Tags: cachefu, plone

Check your Plone site's cachefu setup: small improvements can help a lot. I assume you've got a basic cachefu setup pat down already, which only means adding your few custom content types to the "content" or "container" rules and saying you've got squid (and/or apache) in front. You get good results with that: this blog entry helps you pinpoint some extra improvements.

First the one and only indispensable tool: firefox' Livehttpheaders extension. Livehttpheaders shows you the raw http requests that your browser sends out. And it shows you the requests that comes back: are the caching headers that you would expect really there?

A word of warning about firebug for those that use it to monitor files being read (the "net" tab): it also shows the javascript and css files that are parsed. Also when fetched from the local browser cache. I was fooled by this once: "they should not be downloaded, why are they showing up?". Livehttpheaders disabused me of that false notion.

If I only have one screen, I normally open livehttpheaders in firefox' sidebar. Some problems are quicker to spot that way than by switching back and forth between windows. Disadvantage: horizontal scrolling if you want to look at details. The jackpot: dual screens. One for the website, one for livehttpheaders.

Now get cracking. Pick two or three typical pages.

  • Load them and look at livehttpheaders: what gets loaded? Load them again: what is loaded now? Should some items (images, stylesheets) be cached? What did you expect? Write down the possible problem spots. If something is fishy, use livehttpheaders to check for faulty if-modified-since headers and so.
  • What I find often: I forgot a custom content type. Or a special view is used on a content type, but cachefu doesn't know it should should also cache that view. In that case add the content type and/or the name of the view (or template).
  • Double-check by doing a forced reload. Old locally cached copies don't always have the latest header information from your previous tweaks. Make sure you're not chasing long-solved ghosts.
  • On the site I tested yesterday, squid wouldn't cache certain things I expected it to cache. Ah! We moved the site from 2.0 to 3.0 and there was an old authentication cookie that the current PAS doesn't use. But squid still looks for it, sees it, treats you as a logged-in users, sends you right over to plone: no squid caching. If something like that happens: purge your domain's cookies.
  • Can you relax the caching somewhat? Cachefu's defaults are - of course - pretty conservative. Take images. (Images in your site, not filesystem images). Normally they are cached by squid; the browser is told to always check for newer versions. Most-times a quick "304 not modified" is given back. But still: a request for every image. For the site I optimized yesterday, I changed the used header set from "cache in squid for 24 hours" to "cache it in the browser for an hour". You give up potential freshness, but the images in this case would rarely change anyway. As the same pages (with quite some images) would be requested over and over again, this slashed 90% of the number of requests. Even if they would have given 304's, every omitted request still counts, especially in those numbers.

There you have it. A couple of hints to help you get started with basic CacheFu tweaking. You can get a lot of mileage out of it, without having to write custom rules or header sets. Though that is fun and satisfying, too.

(Old imported comments)
"Okay, it's fixed in trunk already" by on 2008-02-18 00:48:40

Ahh... thanks. I didn't realize that the __ac_name cookie had ever went out to the browser. I just thought it was always just something inserted into the request object during authentication. But I didn't check this as far back as 2.0.

Anyway, the trunk version of the configs test just for "__ac=" now so this should be a non-issue in the next release.

"__ac_name cookie" by reinout on 2008-02-17 21:13:20
Not a custom squid config. iirc, the squid config searches for both __ac (new) and __ac_name (old) cookies. Somehow there was an old __ac_name cookie in the browser cache that was valid for a few years somehow. That one was from the old plone 2.0 site. We moved the site to 3.0, but that doesn't get rid of the old cookie.
"Old authentication cookie?" by on 2008-02-12 00:40:59
Can you clarify the old authentication cookie issue? Was this a custom squid config? logo

About me

My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):