Cacheable and non-cacheable content and why very large TTLs are not always a good thing.
Posted by Max Robbins on October 25th, 2010When aicache is concerned, content can be divided into 2 broad categories: cacheable and non-cacheable . It also helps to think of cacheable content as one that can be shared and non-cacheable content as one that should never be shared or offers no merits when cached.
Certain content on your web site might change frequently, as often as once every 5 second or once a minute. Other content does not change that frequently. Some changes once every hour, some change once every day and so forth.
We must configure Aicache to obey our “document freshness” rules to maximize the benefits of caching: improving overall performance including performance as perceived by visitors, reducing load against the site’s infrastructure and, ultimately, allowing for reduction of footprint and significant monetary savings.
In our www.acmenews.com example most content on the site is cacheable and we can reasonably expect to have cache hit ratios as high as 95%, depending on the traffic pattern.
For example, if 100 req/sec come in for the home page and we cache it for 20 seconds, we will serve 20*100 – 1 = 1999 requests out of cache and only 1 from origin. The resulting cache hit ratio is a cool 100%, for all practical purposes. As a result we have reduced the traffic to the origin server by … drum roll … nearly 2000 times, for this particular URL! Of course, if we only get 10 req/sec for that URL, then reduction will ‘only’ be a factor of 200 .
Clearly, if most content on the site can be cached in a similar fashion, we can reduce the load on origin infrastructure to nearly 0.
Yet as we go about configuring the caching rules, it is important not to be carried away. As you can see, caching frequently requested URLs for only 20 seconds already delivers tremendous benefits ! As Aicache allows downstream caching for the same amount of time as the TTL value, it helps to extend caching of Content Style Sheets (CSS) and JavaScript (JS) file to may be 1hr, so as users visit your site, their browsers don’t have to refresh auxiliary content every time they go to a different page.
But if you allow caching for say 1 day, you lose ability to have the content refresh itself within reasonable amount of time. So if and when you need to modify content of JS or CSS file on the origin servers, it will take up to 24 hrs for it to get refreshed by aicache and visitor browsers too. Clearly situation to be avoided if you do make frequent changes to your auxiliary content! While you can always force expiration of content in Aicache via CLI, there’s no such easy way to do so at visitor browsers, stopping short of publishing a giant “CTRL-F5″ banner on your home page.
Another reason not to jack up TTLs for cacheable content is less obvious, but equally important. Imagine that due a mistake or malfunction somewhere within origin server infrastructure, a broken or invalid CSS or JavaScript file is delivered to, and cached by Aicache and visitor browsers. Again, if TTL is set too high, it will take a long time for that erroneous document to be purged and refreshed.
So the moral of the story is: don’t go overboard with TTLs for JS and CSS, set them to 30m or 1hr to safeguard your site from mishaps and to have ability to make changes to your auxiliary content.
One can argue that images are a different story and will be partially right. Images that never ever change can in fact be cached for an extended period of time (1 week+). Examples include the common 1×1.gif and things of that nature.
Yet photographs are different and the same caveats apply: if you need to have ability to recall/change/expire an image within reasonable amount of time, do set reasonable TTLs. Of course there’re ways to make unwelcome images to disappear from your site’s content by simply editing them out of HTML, but we hope you still get our point.