Stay away from Full-Page Cache By Varnish 5+ Add-On and other cs-cart's Marketplace Performance booster addon!
Both plugins generate cache tags based on the table names used for products and categories.
ver uses the same tags on every cached page, for example, you have cached a thousand product pages. All cache tags are the same.
When you make an update on any product, such as price/stock. because that tag has changed, it drops all caches that use that tag. that is, it deletes the other 999 products and all categories from the cache.
You only figure this out now? I was working on a patch for this like, 6 months ago, but it is to hard to do in the current cscart eco system. Only way to get rid of this is a V5 version, or just optimizing queries in general (which is what I have been doing for the past 6 months).
a friend asked, I looked through him. scam really doesn't work. Yes, I did some experimentation. cannot work properly.
The release time of the V5 is really late. right now V4 is about to turn into disgrace.
Well it *can*. It will just be a lot of work. What I ended up doing is writing an SQL normalizer which was able to conditionally invalidate caches based on configured primary keys. The only downside is that as soon as an 'unknown' table is used in the condition, it is unable to correctly see what the cache key should be. This was working like 99.5% reliably, but the other .5% was really just pain. Another solution, which would be the dirtiest but by far the easiest, is hashing the condition after normalizing it, and then using that as a tag. But this will prevent 'multi level' cache from working.