I have a magento 2.3.5p1 store. It is configured to use Varnish as FPC. Although I have set in magento admin the TTL for one week in server stats I see very low cache hit. Around 5%.

I am suspecting that this is because we do a lot of work in admin, adding new products, magento keeps invalidating the FPC.

My questions are:

  1. Is this right for a platform to use FPC and always be unused? Because you can't have a store without adding or updating products etc.
  2. Is this maybe misconfiguration of my store?
  3. Is there another way to work in admin without invalidate FPC all the time?
  • To follow up on this question I've got a store where product saves on the CLI are massively slowed down because the M2 framework is continually invalidating FPC and taking a while to do so. I've straced the processes and that's all it appears to be doing. The use of Varnish appears to have added a huge bottleneck in terms of saving product data. I am really curios what others would have to say about the subject. Commented Jun 29, 2020 at 11:27
  • @DominicXigen you are absolutely right. In my end I have serious issue because we add and update a lot of products every day from admin. I have never see in varnishstat more than 7% hit rate. Imagine that I have created a script which uses curl to hit all my major links every hour and also I have in Magento cache warmer. Nothing is helping
    – G. G.
    Commented Jun 29, 2020 at 11:34
  • Low cache hit rate may not necessarily be caused by cache invalidation from product updates. There are quite many faulty modules that purge the cache in whole, so watch out for those. If using custom scripts for product updates - make sure no unnecessary updates are being done, and furthermore, it's relatively easy to add code that "warms related page cache upon update", so that real users won't experience slowdowns. Commented Jun 29, 2020 at 21:29
  • @DanilaVershinin when we stop working in admin we see significant increase of speed in front end. Also how can I find if modules invalidate cache? The thing is that magento 1.9.x(latest) was rocket speed...Now we all migrated to magento 2 and we have these things....
    – G. G.
    Commented Jun 29, 2020 at 22:08
  • @G.G. this is precisely why I keep telling everyone who's seeking M2 upgrade to think twice and change their mind. You can find the log function for cleared cache in Mirasvit Cache Warmer. Thanks to that I found at least swissup plugin at fault. They promised to release a fix (and I'm sure they did), but this says it all how "well" those plugins were tested! Commented Jun 29, 2020 at 22:14

1 Answer 1


Not a complete answer but you might find useful.

Use this snippet to find all extensions with cacheable="false"

find vendor app -regextype 'egrep' -type f -regex '.*/layout/.*\.xml' -not -regex '.*(vendor/magento/|/checkout_|/catalogsearch_result_|/dotmailer).*' | xargs grep --color -n -e 'cacheable="false"'

If you've got a lot of these throughout the frontend that will prevent cache hits

  • DominicXigen will check this. Also I found something else in magento code. It seems that every time you update or add products and attributes magento it calling the cache cleaning method before save function. If I rewrite this with a custom module and remove it, what is your opinion?
    – G. G.
    Commented Jul 1, 2020 at 10:36
  • DominicXigen I used your script....It seems that results was as expected....No suspicious "cacheable="false" was found. Tell me your opinion about my previous comment please
    – G. G.
    Commented Jul 2, 2020 at 12:24
  • If you move away from cache clearing asynchronously you will need a separate process which detects and periodically refreshes affected products - but yes, sounds like a good idea Commented Jul 2, 2020 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.