Pre-caching FTW

I just had an epiphany.  I’ve talked about pre-caching content before and the benefits thereof before.  But this is the first time I realized not only that there are benefits, but that doing it is BETTER than caching inline.  Let me sum up… no, there is to much.  Let me explain.

Typically caching is done like this (stolen from the ZF caching docs):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$id = 'myBigLoop'; // cache id of "what we want to cache"
 
if ( ($data = $cache->load($id)) === false ) {
    // cache miss
 
    $data = '';
    for ($i = 0; $i < 10000; $i++) {
        $data = $data . $i;
    }
 
    $cache->save($data);
 
}
 
echo $data;

Pretty easy.  But what happens if you have code like this:

1
2
3
4
5
6
$options = $app->getOption('google');
$client = Zend_Gdata_ClientLogin::getHttpClient(
       $options['username'],
       $options['password'],
       Zend_Gdata_Analytics::AUTH_SERVICE_NAME
);

What’s so important about this code?  Is it because it is of a remote nature?  Is it because it uses GData?  Nope.  It’s because it has a username and a password.  Given the previous caching what happens if that password changes (like mine did)?  Your site is down.

So, why do I now think that pre-caching is better than inline caching?  Look at my front page.  You would never know that I’m currently having a problem because it’s still reading from the same cache key (with non-expiring data).

THAT is why I’m forming the opinion that pre-caching/asynchronous caching not only has benefits over inline caching, but that it may actually be better.  I’m not one to make blanket statements, and I’m not going to.  But I am toying with the idea of using pre-caching as the default mechanism for caching instead of the other way around.

0 comments

Trackbacks

  1. […] this new post to his blog Kevin Schroeder suggests that there’s something even better than doing the […]

Post Navigation

Web Analytics