Speed Booster, Cache, Boost and AdvAgg

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!

1Cache – 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.

2Boost – this Drupal contrib module caches full pages and works only for anonymous visitors. It is supported on the Nginx server configuration level directly, so there is no .htaccess required and used, it works out of the box when the module is enabled. Important: the cache directory required by Boost is already created for you in all platforms installed by default. For custom platforms it is created on the fly, but only if you have enabled Boost in any site created in your custom platform and then you have run Verify site task in Aegir – the order matters. Note that Speed Booster cache takes precedence over Boost cache files, so there will be no Boost’s specific footer visible in the page html source if you didn’t disable Speed Booster first. This module is not enabled by default. You can skip its cache on any URL on demand by adding ?nocache=1 at the end.

3Speed 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 3 hour (hardcoded value), while for logged in users for 60 seconds 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 60 seconds 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 or sites/domain/modules directory. You can skip its cache on any URL on demand by adding ?nocache=1 at the end. Purge and Expire modules are now enabled by default in all 6.x and also 7.x sites. Now Speed Booster works like a Boost – it expires immediately the cache for any node/page as soon as it has been edited or comment added. It also automatically expires the cache for the homepage – but only when the node is promoted to the homepage, however it doesn’t even need to be published. You no longer need to wait up to one hour for Speed Booster cache expiration. Plus, unlike in Boost, it purges all separate caches for all mobile devices along with non-mobile cache, at once. Now you have a good reason to disable Boost and use our crazy fast Speed Booster only. Speed Booster offers now also ESI microcaching, as explained in this article. This may enhance not only anonymous visitors, but also logged in users experience, since it allows you to separate microcache for ESI/SSI includes (valid for just 15 seconds) from both default Speed Booster cache for anonymous visitors (valid by default for 3 hours, unless purged on demand via recently introduced Purge/Expire modules) and also from Speed Booster cache per logged in user (valid for 60 seconds). The ESI module is included in all 6.x platforms but is not enabled and not configured automatically, so please consult its documentation for details on how to use it properly. Now you have three different levels of Speed Booster cache to leverage and deliver the ‘live content’ experience for all visitors, and still protect your server from DoS or simply high load caused by unexpected high traffic etc.

Both Speed Booster, Boost and Redis/Memcached supports separate caches per mobile device, so it is safe to use separate themes or content for mobile devices. We use simple logic to determine the kind of device and there are separate cache bins for mobile-tablet, mobile-smart and mobile-other. You can review it here

When Speed Booster or Boost module is used, then any caching related settings available at the site’s performance admin page are never used, because either Speed Booster or Boost takes precedence over native Drupal caching for anonymous visitors.

?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 high anonymous traffic and many logged in users. Thanks to new Purge and Expire modules supported and enabled by default in all 6.x and 7.x platforms, it will purge any changed page cache immediately, so it works like a Boost module now, with only one exception – expiration time for not purged cache for anonymous visitors is hardcoded to 3 hours, while in Boost you can set it to, for example, 24 hours.

Boost module has no longer any important advantage over Speed Booster since BOA-2.0.2 Edition release.

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.

?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.

4To 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 is no longer an issue starting with 1.0-boa-T-8.8 Edition). See also related recipe for disaster.

! 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 is available starting with 1.0-boa-T-8.8 Edition.

!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 it is also possible to disable Speed Booster system also per site, so the expected path to the control file is: sites/domain.name/modules/ubercart/README.txt.