Cache Management

In Magento caches exist to reduce hardware utilisation for frequently requested content.

  • The admin is never cached
  • The frontend utilises many different caches

The caches used on the frontend vary depending on the content being displayed and the lifetime of the cache entries also differs depending on what is defined in the Magento core.

You will find that adjustments to product data, or CMS content may not immediately reflect the change on the frontend; because one (or many) of the standard Magento caches still retains a stale copy of the data.

Mode

Two modes exist for Magento caches,

  • Enabled
  • Disabled

Production stores

All caches should be enabled at all times.

Development/Staging stores

All caches may be disabled or enabled.

Warning on cache management

A facility exists in the Magento admin under Admin > System > Cache Management and via SSH using MageRun to manually refresh or clear the Magento cache.

Under no circumstances should these facilities ever be used during production hours

Disabling, refreshing or flushing the store caches during production hours will cause immediate and prolonged downtime.

If you must refresh/disable/purge the cache during production hours then select only the absolutely essential caches to refresh. Avoid blanket refreshing/disabling/purging all caches and ensure only the appropriate cache is altered.

You can visualise the impact in real world terms, both for performance and sales, by reviewing the Kibana Local Performance dashboard.

Admin notices

One or more of the Cache Types are invalidated. Click here to go to Cache Management and refresh cache types.

You may often see this notice displayed at the top of your admin panel. This is an indicator that the cache data on the frontend of the store is stale, it is not a cause for alarm. You can and should disregard this message and not take any action.

The Magento cache will naturally expire when it needs to. Leaving the caches to naturally expire ensures you will have a stable, reliable store and uninterrupted sales.

3rd party cache modules

It can appear desirable to "fix" this behavior in Magento by installing a 3rd party module. Unfortunately, this does not work and will lead to considerably more problems.

  1. They are often poorly built and don't scale properly. They create tens of thousands or poorly structured cache files on disk, or badly keyed in Redis/Memcache. Which uses an enormous amount of resources to both manage and seek when a cache hit/check is required.

    Result: It often means that a cache hit takes longer to process than an uncached hit.

  2. The page pre-processing/hole-punching on these modules means the 100ms standard Magento bootstrap hit is often still hit during a cache hit, and the page processing/storage/punching then adds to the page load time (even on a miss).

    Result: Uncached page load times are higher than if not using a cache at all.

  3. The Magento standard block cache is excellent. It doesn't need to be replaced. It will deliver 200ms cache hits and fully supports tagging, hashing and customisable lifetimes.

  4. They are always installed for the wrong reasons. It is a fact that stores are not faster after a FPC is installed. There is an illusion of better speed, but every real-world study conducted that compares the server page load time before/after installation shows load times remain the same, or increase (for the reasons specified above). There are simply too many URL permutations for a cache to be an effective way to improve performance, unless traffic levels are extremely low, or an extremely long TTL (4 weeks+) or the store has an extremely small catalogue with no layered navigation.

    Result: Cache hits are usually <5%, so the "performance" from the cache is never seen in the real world.

  5. The single most important areas on your store are customer registration, cart and checkout. A cache will hinder performance on these pages, not improve it. The time used implementing a cache takes away from time that could be spent addressing actual performance problems. If the store is slow because of a code/database issue, and this isn't fixed, it means there is a real problem that will be blocking sales.

    Result: Sales do not increase because the issue is still there and the store is still slow.

  6. Magento is already extremely fast! You can see 0.5s page load times, with all the Magento caches off. If a store doesn't load in 0.5s with all the caches off, then it requires code-profiling.

  7. The only purpose for a cache is to reduce hardware requirements for frequently requested assets. A store must be fast before using a cache, as the purpose of a cache is not to improve performance, it is to reduce hardware utilisation.