Recommended caches to clear after server deployments?

Question

Craft has this article about deployment best practices: https://craftcms.com/knowledge-base/deployment-best-practices

It also states that you might want to clear caches after deployments, which is of course needed to clear the template cache after code changes, as you'd want them to be visible immediately.

Which caches do you recommend to clear after every deployment? It seems unwise to erase them all after every deployment, so running clear-caches/all is probably not the best way to go at it? This will also clear asset and transforms related cache amongst others, and those would have to be recreated again, which might be unnecessary / a waste of resources.

Maybe just these 3?:

clear-caches/data
clear-caches/temp-files
clear-caches/compiled-templates

How do you handle deployments / cache clearing?

Answer 1

I recommend clearing all caches on deploy via clear-caches/all.

Caches should not be used to mask performance issues, they are used to solve concurrency & scaling, by holding onto data that doesn't need to be recomputed each time.

As such, caches should be ephemeral, and the cost of clearing a cache should not be so expensive that it drastically impacts the performance of the site.

If clearing all of your caches detrimentally impacts the site, probably the caching layer is masking issues with the site that should be addressed.

Important to note: Clearing all caches in Craft CMS does not cause image transforms (which are very expensive) to be deleted on disk.

It's not a matter of if, but when you will spend hours debugging an issue only to find that it's the result of a stale cache. Or conversely, being notified in the middle of the night that there is an issue with the latest deployment that was not discovered until a cache clears.

Web servers are highly complex state machines; caching introduces yet another layer of state that adds more complexity that you don't want to spend your time diagnosing and debugging.

Selectively clearing caches means you have to fully understand what each cache does, and all of the potential impacts and interplay involved in not clearing it. This can be more complex than it seems at first blush.

Selectively clearing caches also means that you need to ensure any new caches introduced by Craft or plugins are evaluated, and then you may have to go back and retroactively add to your list of caches to clear for each site you maintain.

It's probably not the most effective use of your resources to do so; better to spend your time optimizing your site, and clear all caches on deploy.

You cannot do truly atomic deployments while keeping stale cache data intact. ref: Atomic Deployments Without Tears

Answer 2

This is a complicated question, because... it depends :)

Clearing all the caches is often cited as a good practice, because it completely avoids any potential problems due to stale data, during or after deployment. It's a single, swift stroke that will even include any future caches that might be added to your site.

On the other hand, clearing all the caches is overkill for the vast majority of Craft sites – and depending on what's being cached and how the site is built, hosted and deployed, the additional overhead can potentially introduce unnecessary performance issues.

As a general baseline for the typical Craft build, I'd say clearing the following caches should generally be sufficient:

clear-caches/data
clear-caches/compiled-classes
clear-caches/compiled-templates
clear-caches/cp-resources

Additionally, you could have plugins installed that create their own caches that might also be a good idea to clear.

For most builds – assuming the site is relatively optimised – the performance impact in clearing the caches above should be negligible. These are also the caches that would be most likely to introduce issues after deploying new versions of the site (or Craft itself), in the case that they contain stale contents.

Note that in order to use the clear-caches/cp-resources command, you typically need to explicitly define the @webroot alias, as described in the official docs:

return [
    ...
    'aliases' => [
        '@webroot' => dirname(__DIR__) . '/path/to/webroot',
    ],
];