Search code examples
phpmagentocachingredisenterprise

What does "Refresh cache" mean in Magento?


Here is what I found after investigating cache behavior in Magento.

I'm not sure of this and asking for correction.

When something like a product is modified, cache entries such as "HTML Block" becomes "invalidated", resulting on being ignored and not used in frontend. This makes sense because these data is now outdated.

It remains "invalidated" until manually "refreshed" through admin area.

Once manually "refreshed", the first render of a cached block will construct its cached copy and append it to this HTML Block cache reserve. Subsequent render operation of this block will find this cache usable, and use it, finally, until cache becomes "invalidated" over again.

Why this process is called "refresh", as it should be something like "reset"? because "refresh" would means it generate updated cache snapshot, but instead it merely allows cache entries to be constructed.

Why don't invalidated data become refreshed once it's invalidated?

This makes me question my conclusion, was I correct?


Solution

  • why this process is called "refresh", as it should be like "reset"

    Your general take on this is correct -- some people call it "refresh" because although the action you take resets the cache, in a working Magento system the cache will almost immediately rebuild itself the next time you (or another user) loads the page.

    Why don't invalidated data become refreshed once it's invalidated?

    When the cache is invalidated, that means the developer working on whatever backend feature invalidated the cache was smart enough to know their actions required a cache refresh, but that that programatic cache control wasn't sufficient to refresh only their portion of the changed cache.

    For example, certain blocks might render a change in a product's price, which means any blocks with the price cached need to be refreshed. However, as a backend programmer, there's no way to know which blocks need that invalidation, nor know which cache system (block cache, FPC, varnish) they're stored in. There's also a question of store performance -- if you're editing 100 products, do you want Magento to rebuild the cache 100 times during peak traffic hours? So, instead of deciding how to handle all that, the developer marks the cache as invalidated. This allows the cache system to take whatever action it deems necessary.

    In a perfect theoretical cache system, there would be automated processes running that would detect an invalidated cache, and know what to do and when to refresh it. That's a complex system to implement and maintain, so instead Magento chose to simply notify the store owner's of the invalidated cache, and let them take whatever action they deemed appropriate.