Recently a user in the Associate-O-Matic forum asked about the caching system in AOM and how it worked. It seemed like a good subject to cover in more detail, so let me expand here on my original reply.
The purpose of the cache system is to reduce the number of calls made by AOM to the servers at Amazon. By caching, or storing pages on the server your store is located on, it can pull that data up faster than reaching out to Amazon for it. And by putting in fewer requests, it can help your site with usage restrictions imposed by Amazon. The tradeoff is that the more caching you do, the more storage space is required. So it’s a case of speed vs. space.
Pages are cached for the number of hours determined by the Cache Lifetime setting. The default is 24 (hours), which corresponds to Amazon’s pricing rule (pricing must be updated at least every 24 hours). After that, the page is expired, and a new version is pulled when/if someone tries to access that page again. The new version is then cached for however many hours the Cache Lifetime is set for.
Once the page is expired, the Cache Cleanup setting determines the odds of that page being deleted from the cache. So “20” would mean odds of 1 in 20 of any particular expired page being removed at any given time. The lower the number (say 1 in 10) the more aggressive the cleanup is, at the cost of site performance. As the number is raised (1 in 30, etc.) the better the performance, but more disk space is used to store the larger cache.
It’s important to understand that there are two separate things going on:
– When a page is requested from Amazon, it’s cached for whatever the lifetime setting is (say 24 hours). Within that time, if it’s requested again, the cache copy is used. Either way, eventually the page expires. If it’s requested after expiring, a new copy is pulled from Amazon. If it’s not requested again, it’s simply expired. And once a page expires, it won’t be used again. It just takes up storage space until it’s cleared out.
– Every page has a one in whatever chance of being removed after expiring. It has nothing to do with how many times the page is requested. The cleanup function only deals with expired pages, which by their nature cannot be requested. Requesting an expired page will result in the same action as a page that’s never been requested – it will be pulled from Amazon.
The Cache Cleanup doesn’t run every time so as to not impact performance. But it will clear out your cache whenever you open your control panel and click on any Save button. In the bottom left corner you’ll see information on how many pages are cached and how much space is taken up by it.
The AOM download page includes an extras file you can get that contains an aom_cachecleaner.php file. This is a separate program that can be run as a cron job to manage your cache files without affecting your store operation. Instructions are included, but it’s a good idea to have some knowledge of how to operate cron files.
The three remaining options on the Cache tab allow you to control whether or not caching will be allowed for the header and footer, as well as the RSS feed. Caching the feed is a bit of a no-brainer, but there may be instances where shutting it off is advisable (such as severe storage space situations). Otherwise you’d almost certainly opt to leave it on. So let’s discuss the header & footer issues in slightly more depth.
Most of the time, you would leave these on as well, since there’s no good reason not to. But in some cases, a site might use a custom header and/or footer file that accesses external data in real time. A ticker that displays the results of sporting matches, for example. Or a live webcam, twitter feed, etc. In these situations, caching would not be advisable, since the information in the header or footer would only update when the cache was refreshed, possibly once a day. But turning caching off for the store might also pose a problem.
In such cases, turning off the caching just for the custom header and/or footer files would allow them to update when needed, and enable the store’s product data to be cached. The only downside is that information that would normally be passed to these files, such as the current page title or meta info would not be updated. This would be more of a concern with a header file than a footer file, so it might be advisable to put a twitter feed, etc. in the footer rather than in the header. But it’s worth mentioning again that these are very special cases; under normal circumstances, you would just leave the caching turned on.
Hopefully this sheds a little light on the caching system. Unless you have specific reasons to do so, leaving the default settings in place is probably the best option overall.