Caching

Front End Caching

So you think you want to cache do ya? Of course you do! Caching is a very broad topic, and if you want to get serious about it there are plenty of books and, god forbid, you can read the spec on it. I'll try to cover the useful basics here. The thing to remember about caching is WHY you are caching - you are trying to avoid any unnecessary requests from hitting the server, and if they do hit the server, keeping the response as small as possible. Your server doesn't want to server user.gif for every page, and your browser doesn't want to render it. Luckily, any caching you do benefits both of these players.

 

Please note that I'm purposely omitting a CacheFu or Httpd acl HOWTO - if you understand the basics then using these tools will be easy. Everyone has their own preferences as to which they prefer, and most systems.

 

Debugging

• LiveHttpHeaders - Before you do anything, you are going to need to get a tool to read the http headers coming across. I recommend using firefox and the LiveHttpHeaders tool, or something like that. Don't think you can install this and everything will magically make itself relevant - you have to READ and understand these headers. READ them. Need help? READ them and then post to a board. With an hour of practice you will become a header master.
• Enable/Disable Caching - You will also need to work with and without cache enabled to see whats coming through for both first time visitors and return visitors. In firefox, you can do this by typing about:config into the address bar and then filter the results on cache. 

Tools

• CacheFu - CacheFu is a product that comes with every new plone download. It provides back end caching, as well as default html caching header configurations for a default plone install. If you do any product customization, you will not reap the full benefit of cacheFu without customizing cachefu itself. It's a great product, but not a miracle worker. Read the Zest Software documentation for making the mostof CacheFu.
• HTTPD/Other Web Servers - You can also manually set your own headers based on content types in apache httpd and other front servers. This is often your least path of resistance, but may give you not enough control. In general, start here and then work back into the stack.

 

"Levels" of Caching

Here are things to know, ordered from the most ideal situations to the least.

• Cache forever: If you have content that doesn't change ever, the best thing to do is cache it in the browser forever.  If you cache forever, the browser will never attempt to make a trip to the server to get the resource as long as its in the cache. This is best for resources like css, js, and sometimes images. Plone has already done some things to help you out here by generating unique ids for your resources when they are changed, meaning that 99% of the time you can safely cache in browser forever. There is a caveat to this - see below.
• Cache for a while with Expires: Things like images, landing pages, infrequently edited pages, anonymous content can be cached for a certain amount of time, say 1 week, 1 day, or even 1 year. For people who update css and js a  lot, this is probably a good option as well. Basically you are telling the browser - hey - keep this in your cache for X time. After that, throw it away and get a fresh copy. This is almost as good as caching forever.
• Cache until modified: When you need to have the content validated, 304s are here to save the day. The browser sends a If-Modified-Since (IMS) request to the server when a page is requested that is in the cache. The server looks at the date of the cached file, and then the date of the content to be served. If the content has been modified since the browser last requested that page, it sends a new copy of the page. If it hasn't change, it send a teeny tiny response called a 304 (Not Modified). This is ideal, since just a small amount of data is sent across the network, reducing network time as well as rendering time in the browser. How does Plone tell if something has been modified? The catalog knows! And cachefu has great tools for easily incorporating this header. IMS headers are great for anonymous content that is frequently modified.
• Cache with etags: When you have authentication requirements, etags are where you want to spend most of your time. I'm sure there could be a small book written on etags, but if you really want the scoop, read the spec. Seriously. Etags allow us to do If-Match (IM) requests, which are like IMS requests on steroids. An IM request is sent to the server that asks "hey server, the last time I loaded this page I was sent this etag in the header. Has anything changed since then?". The server compares the old etag with a new one, and if nothing is changed, simply says "no, we cool" in a tiny little response message. If things have changed, it sends a new copy of the requested page.  The etag almost always contains the username of the user who was online when the page was cached, but its really up to you what variables you want in it. I can't figure out how to make a new paragraph in bullet points so I'm going to keep rambling. For example, say you are looged in as admin and you view index.html. The etag may look like "12353453.34534|admin", which is last modified time|username. The IM request will send this tag back to the server the next time you go to index.html. If you logout as admin and login as foouser, the new etag for that same url at the server will look like "12353453.34534|foouser", so the server decides that this is NOT the same page that is cached and re-render that page. The re-render is important, since it checks permissions for foouser instead of admin. You chose what makes up your etags and with cachefu configuration you'll see where they are listed. HINT: the defaults here are probably overkill. You can get very, very far with last modified time. Also be aware that these will take precedence over any expires headers so make sure you are not fighting yourself.

• No caching: You can configure to not cache things, but then you probably wouldn't be reading this section so I'm omitting details here.

 

Gotchas

• Internet Explorer has a tendency to not behave like the others when it comes to caching. For example, it may cache a page but not its resources, or vice versa. So why could does this suck? Well, say that you generate 1 version of a page pointing to a css file, plone12345678.css. Browser caches the page and not the resource. You do a reinstall and the css file is called  plone12345679.css. When IE loads the cached page, it reads the css resource line and tries to load the old css file, plone12345678.css, which no longer exists in plone. The final result is a rendered page with no css applied (yuck). If you care serving your css outside of plone, this is not an issue since you will have a copy of each generated file on the system.
• Technically, browsers are not supposed to cache ANY pages that were served with SSL. However, most browsers have an advanced option to turn on SSL caching, and many have it turned on by default. Your big problem here is probably, again, going to be Internet Explorer. It has a very specific rule to not allow caching of "file" files in the cache/temp internet storage. Instead of just not caching it, it will not download at all and it manifests as what looks like a server error. If this is your case, look at the advanced options to allow this storage, since its not set by default.

 

Back End Caching 

So you're browser caved in and has requested a page. Chances are everyone else's browser did too. How can repeated page renderings be cached? What about expensive database operations or calculations? Fear not young scallywag for there is help!

• _v_ is for volatile: If you have an expensive calculation or database call, consider storing the results in a volatile attribute. Not that this is not stored between zopes, but at least repeated calls to a function within the same page render will be cached. This can be especially important if your transactions are retrying a lot or if you have something in the core of every page. Read all about it.

• plone.memoize: If you want to simplify and have a hankering to get your teeth on some decorators, try out plone.memoize. It offers many levels of caching in memory (some shared between zopes and some now) which will satisfy basic cases just fine. Most hardcore issues will want to work with memcached on their own though, so you might want to think twice here and heed the warnings.
• CacheFu: CacheFu not only serves up sweet headers for front end caching, but it also cache the post render page in the backend. This can be confusing to newbs so make sure you know who is caching what where.
• MemcachedManager: The good: this little gem of a product gives you direct access to Memcache from all zope instances: shared memory FTW!  The bad: it's not the best access, and memcached is yet another service to maintain. The ugly: If you are starting to use memcache for anything besides page caching, you are probably over-optimizing. It's easy to abuse, so really think hard before getting this install up and running. If you have hoards of zopes running, you can programatically force your resources to be served from memcache and save a heck of a lock of re-rendering. Code coming soon...
• Custom Caching: In 50% of cases, one or a combination of the things above will *help*. Anything else and it's just better to install memcached and the python-memcached bindings (or something similar) and roll your own. Its easier and quicker because every application is different; only you know where your bottlenecks are. The api is actually quite easy so don't be afraid to dive right in. There is a C version for those requiring mega performance, but if you are that far gone, bon voyage sailor.