The Digital Tool Factory Blog

I recently implemented a quick performance fix on a client’s site recently by implementing caching.  I explain caching with the following metaphor.

Imagine that your site is a book.  A book written in a weird mix of Latin, Sanskrit and Old Norse.    It’s precise,  complicated and requires translation into English by an expert translator before it can be read by the public.

Your web server translates the book.  Anytime, someone tries to read the book they cannot read it directly; they need someone (the web server) to translate the book.  This can take a lot of time and energy for the translator to do, but it has to be done.

A simple version of the process

To clarify, the process works like this

1. Person makes a request, i.e. “what does that book say? [Non Resource Intensive Step]
2. The translator looks at the book, and makes a careful translation into modern day English of the book from the original Latin, Sanskrit, and Old Norse.    This can take a long time [Resource Intensive Step].
3. After the translator completes the translation he sends it on it’s way to the person who made the request [Non Resource Intensive Step].
4. The person who makes the request receives the translation and the interaction is complete [Non Resource Intensive Step].

That all sounds good, but the problem is that the four step process has to happen each and every time anyone makes a request, especially the resource intensive step two.  So, if a web page gets 1000 requests an hour, resource intensive step #2 runs 1000 times.

The first request with caching

Now imagine if the translator makes a copy of the English translation after he sends it out the first time.  The first time someone makes a request for a translation the process looks like this.

1. Person makes a request, i.e. “what does that book say? [Non Resource Intensive Step]
2. The translator checks to see if there are any photocopies of the translation that are less than an hour old [Non Resource Intensive Step]
3. The translator looks at the book, and makes a careful translation into modern day English of the book from the original Latin, Sanskrit, and Old Norse.    This can take a long time. [Resource Intensive Step]
4. After the translator completes the translation he makes photocopies of the translation. [Non Resource Intensive Step]
5. Then the translator sends the photocopy of the translation on it’s way to the person who made the request. [Non Resource Intensive Step]
6. The person who makes the request receives the translation and the interaction is complete. [Non Resource Intensive Step]

Subsequent requests with caching

Subsequent requests for the book look like this

1. Person makes a request, i.e. “what does that book say? [Non Resource Intensive Step]
2. The translator sends the photocopy of the translation on it’s way to the person who made the request. [Non Resource Intensive Step]
3. The person who makes the request receives the translation and the interaction is complete. [Non Resource Intensive Step]

The first time someone makes a request the process runs a little slower, but since each subsequent request for the book omits all of the resource intensive steps, the whole process take up much less time and fewer resources, making for a much lower delivery time on average, e.g. for every 1000 requests for a page, resource intensive step #2 runs 1 time, not 999 times.

Making a photocopy is pretty close to caching.  The web server makes a copy of the page it just created and sends it on it’s way to web browsers.

What are the downsides of caching?

What are the downsides of caching, and why doesn’t everyone use it?   I’ve seen two main reasons not to use caching.

1. The contents of the book can change unexpectedly.  If it does, then the translator is handing out old editions of the book.  That might be fine for some sites, but for others it might be catastrophic   For example, if a blog serves up a slightly out of date version of a post no one will care that much, but if a stock market application serves up old stock prices people will care a lot.  With caching, the translation/web page can be up to an hour old.
2. It makes debugging much harder if everyone sees slightly different versions of the same thing.

That’s how I explain caching to clients.  I’ve always had people find the metaphor clear and easy to understand.