HTTP Caching on Tailrank

Well I had a productive evening!

Check this out. I finally fixed a long standing bug with HTTP caching in Tailrank.

It turns out that Mozilla/Firefox sometimes specifies Cache-Control: no-cache on HTTP requests. Normally this would force the server to refresh the page on behalf off the client. The only problem is that this was kicking in for all HTTP requests and never returning from the cache.

This is obviously a bug in Apache 2.2.

I also took the liberty and updated the HTML page to load the right sidebar after the main content to give a slight perception of faster loading on the client. Eakes came up with this technique while we were at Rojo. You don’t actually load the page faster – you just make it seem faster by loading the primary content first.

The results below speak for themselves (thanks grabperf!)



I’m still confused by the results though. There shouldn’t be any latency for pages served from cache. These results are showing from 200-600ms. It should be 0ms.

It turns out there’s another bug where the cache can only store one type of encoding. If grabperf isn’t using gzip encoding then it will trigger a cache flush (same with nagios).

  1. I may misunderstand the analysis or be missing some facts, but if that second bug is causing cache misses on every request from grabperf, then why did you see a performance change after the Apache tweak? Wasn’t it missing the cache both before and after?

  2. Andre. I *think* because I changed the page size down from 30 to 10 items.

    I still think its flushing the cache so I’ll play with this tomorrow.

    The page should literally be sitting in memory waiting to be served so I should see times of zero milliseconds.

  3. Hi Kevin.
    I’m confused.
    why aren’t you using cacheignorecachecontrol ?

    that will ignore what the browsers say.

    also reducing what the page does by 300% (30 to 10) would probably have an effect as well.. If your going to highlight how fantastic you change is.. you need to do it by itself… otherwise people (like me) are going to bitch on your blog about it ;-)

  4. Its not the kind of ignore you’re thinking of:

    “CacheIgnoreCacheControl On tells the server to attempt to serve the resource from the cache even if the request contains no-cache header values. Resources”

    This means that if the browser says Cache-Control: no-cache then we ignore it… which is good because the browser sends this on Shift+Reload.


  5. I send the following lines in the GrabPERF Request Header:

    my @myheaders=();
    $myheaders[0] = “Pragma: no-cache”;
    $myheaders[1] = “Cache-control: no-cache”;

    So I am passing through cache every time… :-D

    Do I hear a feature request?


%d bloggers like this: