Our high performance Barracuda Octopus Aegir LEMP stack (BOA) has already a few levels and kinds of caching enabled or available, so it is important to understand how all those performance related modules and systems work to leverage all its power and avoid possible side effects or confusion.
We will explain all this performance magic in detail below. You will learn some secrets about Cache, Boost and AdvAgg modules and also the Speed Booster system. We will also discuss When & How to use all those available features. Let's begin!
Cache - this Drupal contrib module implements Redis and Memcached cache servers support, and works both for logged in users and not-yet-cached in Boost or Speed Booster, anonymous requests. It caches only some cache specific tables to lower the load on the database server. This module works only in 6.x core based platforms and is enabled by default. However, it is disabled on the fly when you access the site with "dev" type subdomain alias.
Boost - this Drupal contrib module caches full pages and works only for anonymous visitors. Its cache files take precedence over Speed Booster cache files, so when enabled with Speed Booster cache, can provide a better control over cache expiration times (in theory). This module is not enabled by default.
Speed Booster - this is not a Drupal module, but our system level configuration, Drupal version agnostic, enabled by default. It caches full pages, but both for anonymous visitors and logged in users, however for anonymous visitors it is set to be valid for 1 hour (hardcoded value), while for logged in users for 5 minutes only (also hardcoded) - with separate cache per user, thus far better than existing AuthCache module (not supported here). It is automatically disabled on the fly for all requests if you are using "dev" type subdomain and for all domains if you click on any URL like /user* /admin* or when you will add new content or new comment. It is also disabled automatically, on the fly, for the next 5 minutes for anonymous visitor if he/she just added a comment, to avoid "where is my comment?" confusion. This system is automatically disabled on the fly also for all HTTPS requests, for any site hosted on the Commerce platform and any other platform with Ubercart module existing in the sites/all/modules directory.
Now, which module/system to use? Maybe all of them? What are the advantages and possible disadvantages depending on the site's target audience and use?
The Speed Booster system is better for sites with many logged in users and lower priority for instant updates for anonymous visitors.
Boost module is better for sites with low traffic of logged in users and high priority for instant updates for anonymous visitors.
Cache module (Redis+Memcached integration with standard database automatic failover) is always useful, especially for logged in users, but it is possible (rarely, but still) it will conflict with some modules if they are trying to purge the cache tables too often - you will see when this happens, because it results with very slow page generation times/ratio and then the solution is to disable the cache integration for this site or platform, which can be done on the fly, as explained below.
In theory having Boost and Speed Booster enabled should allow for better control over the cache expiration time, because Boost cache takes precedence, however it will work as expected only with Boost cache set to be valid longer than Speed Booster cache, so the Speed Booster cache will expire earlier and anonymous visitors will see always the pages from the Boost cache.
Another reason to have both enabled is when you want to have better control over anonymous cache expiration but you also want to use fast Speed Booster cache for logged in users.
Both Boost module and Speed Booster system can suffer from the common "broken layout" issue, caused by Drupal standard core behaviour - it purges all aggregated CSS and JS files on standard cache purge action on the performance admin page (the 'Clear cached data' button) or even on certain form sumbit actions, while pages still existing in the cache still reference no longer existing aggregated CSS and JS files.
To fight with this common isse, you may want to use excellent AdvAgg module, so aggregated CSS/JS files will not be purged/recreated/renamed, but only rebuilt. To quote this excellent module description: "This is the holy grail of CSS & JS aggregation and optimization. If you want your website to load faster, install this module. If you think flushing your CSS/JS directory on certain submit forms is a dumb idea, you should install this module. If you like the idea of using Google's CDN for jquery.js, install this module. It also aggregates JS in the footer. JS minification/CSS compression.. you guessed it install this module. Gzip CSS/JS files, yep it does that too! Using a private file system? Use this module and bring back aggregation for improved performance! Wish you could use the same aggregate on different pages, guess what? Install the bundler submodule and watch in awe of how fast your site loads."
Your Aegir system is already AdvAgg ready, and the module is expected in the platform space: sites/all/modules (or, starting with 1.0-boa-T-8.8 Edition, in the site space: sites/domain.name/modules), but is not included by default. With this module uploaded, you will be able to change the standard CSS/JS aggregation settings at admin/settings/performance page to disable them (it is a required step), as they are no longer hardcoded by default if the AdvAgg module exists. This also means that you will need to either enable AdvAgg module on all sites hosted on the same platform, or enable standard aggregation manually on any site without AdvAgg module enabled (this will be no longer an issue starting with 1.0-boa-T-8.8 Edition).
Note also that due to its "imagecache-like" behaviour, all requests/page views after enabling AdvAgg module will take more time to process, until it will generate enough aggregated files. It is normal, one-time process and later you can use the smart "Flush AdvAgg Cache" button at admin/settings/advagg to rebuild only required files sub-bundle instead of purging the cache completely. This also means, that with AdvAgg module enabled, you have to use this smart "Flush AdvAgg Cache" button after you modified any existing/aggregated CSS or JS file in your themes.
Hint: to disable Cache integration per site or platform, you have to create an empty directory with the name "cache" (and this shouldn't be a real cache module!), with one empty NO.txt control file inside, so its path will be, for site level: sites/domain.name/modules/cache/NO.txt, or for platform level: sites/all/modules/cache/NO.txt (the upper case in the NO.txt filename matters!) Note that this extra switch will be available starting with 1.0-boa-T-8.8 Edition (not yet released but available in the Barracuda/Octopus HEAD).
Hint: to disable Speed Booster system per platform, you have to create an empty directory with the name "ubercart" (unless you have there the real ubercart module already), with one empty README.txt control file inside, so its path will be: sites/all/modules/ubercart/README.txt (the upper case in the README.txt filename matters!). Starting with 1.0-boa-T-8.8 Edition (not yet released but available in the Barracuda/Octopus HEAD) it will be possible to disable Speed Booster system also per site, so the expected path to the control file will be sites/domain.name/modules/ubercart/README.txt.
Hint: while it is not possible to purge the Speed Booster cache in the hosted environment, (by default valid for 1 hour for anonymous visitors) you either need to disable it completely and use Boost only, or when you plan to make some changes to themes/css/js you need to disable the Speed Booster system one hour before you will introduce changes and purge aggregated css/js files. When you are disabling Speed Booster and there are already some cached pages in its cache, they will be served until they expire (1 h max) because disabling Speed Booster prevents only further caching but doesn't purge anything - it is a passive, fast cache. This is the cost of using high performance caching on the web server level, without any connection to the backend, Drupal app. If you are on your own server with root access, you can also purge existing Speed Booster cache with this command: $ rm -f -r /var/lib/nginx/speed/*. Otherwise you need to wait until it expires, as explained above.