HTTP Cache Rework

[shyim]

Context

Currently, the caching is implemented in store-api layer and therefore requires object caching
to be shared between default storefront and store-api.
On top of that layer, we have http caching in the storefront as full-page cache.
When a user is authenticated,
the http cache will be disabled due to the active context rules of the customer,
and only the object cache will be still used based on the context rules.

Additionally, external systems often update products and categories very frequently. Consequently, the cache is invalid most of the time.

tldr:

• HTTP Cache is not used for authenticated users
• The object cache key contains the context rules, therefore the cache is dependant on rules created by the shop owner, and is potentially ignored completely
• The cache is mostly invalid due to the high update rate of products and categories

Decision

Only use HTTP Cache

We will remove most of the object caches in the store-api and move the caching to the http layer.
The object cache will be only used for caches,
which are necessary for almost all requests such as the base sales channel context cache.
This will help us to: reduce the complexity of our cache system, reduce the size of redis caches, reduce the number of cache keys.

HTTP Cache for store-api

As we will remove the object cache in the store-api layer, the store-api will be completely cached via http cache.
This will improve the performance of a majority of the store-api and reduce the load on the application and database server.

Improving Cache key hit-rate

We will simplify the Cache key permutation and remove most of the context rules from the cache key.
As a result, the cache key will only contain:

• sales channel id
• language id
• currency id
• tax state
• customer group id

The cache compatible context rules are a subset of the context rules,
which are compatible with caching procedure as they only use a limited range of information (the list above).

To still support customer-specific pricing, we will load the prices with ajax request and replace them in the storefront.
Custom projects can still customize the cache key, by creating custom cookies and configuring them to be included in the cache-key or subscribe to a specific event.

shopware:
  cache:
    cookies: ['my-custom-cookie']

Improving cache invalidation

Cache invalidations are a very expensive operation, so the goal is to reduce the number of invalidations.
So we enable the delayed cache invalidation by default and collect invalidations for a configured time frame
(default 1 hour) and then soft-purge only the cache.
The soft-purge will mark the cache as stale and will be refreshed on the next request,
so that the customers will always surf against the latest cache.
In some updates the cache invalidation will be forced and directly purged, for example when:

• a product is deleted
• a product price is changed
• a product goes out of stock or in stock

Also provide a dedicated header to clear the cache directly on API written:

POST /api/product
sw-invalidation-force: 1
# ...

Introduce ESI tags

To reduce the number of invalidations for isolated small changes, i.e: category changes invalidating the whole cache,
we introduce Edge Side Includes (ESI) tags and use them for the storefront header and footer.
The header and footer are the most common parts of the storefront and are mostly not changed,
but when they change only one cache entry will be invalidated and not the whole shop cache.

Consequences

• The cache key will be much simpler and increase the hit rate
• ESI tags can be used as an alternative to ajax requests in the storefront
• Extensions have to adopt the new caching system
• Individual content on cached pages will be loaded via ajax requests, computed on the client-side or via ESI tags
  • Individual prices are by default only considered for the new cache key, customer-specific prices need to be loaded via ajax request/esi tag

[aragon999]

I am not sure if it a feasible idea, but it might be worth to think if one can specify the relevant cache keys for the edge side includes (ESI). For example imagine the categories shown in the navigation are by default not dependent on the customer group, so all customer groups could have the same navigation, but the language is still relevant.

Furthermore one needs to think about how plugins can add their own cache keys for each ESI sub request, probably through an event, for example when the navigation should be dependent on the customer group.

But it might also be that this adds to much complexity to the cache mechanism, just an idea :-)

[OliverSkroblin]

Great idea 😉 .

This would mean that we have to teach the reverse proxy to consider different cookies for each URL, right?

So with ESI, this should be quite simple since it is not an SEO url. For the document request per route, I think the whole thing looks much more difficult.

With the integrated HTTP cache, this should even be possible somehow via plugin configuration.

With Fastly or Varnish, I see there honestly rather black

[aragon999]

Yes for now it was only meant to be for ESI requests.

I am also not sure, if the caller side should decide on the cookies which are used, or if they should be associated with the route itself and fixed per route.

If they can be defined on the caller side, it might be easier to change that for example from within the template. But maybe one also does not want to give such power to template engineers as it might be easy to screw up there :-D

[mnaczenski]

In the past I encountered always two issues with the http-cache:

• terrible cache-hit rate
• huge amount of data stored in the cache

So I think it is important to really define invalidation rates on site-level (e.g. product detail pages, listing pages, navigation?,...), because there are a lot of shops out there where the listing needs to have a high hit-rate, but it is nearly impossible to get a high cache-hit rate with 500.000 product detail pages. So I might want to have the listings cached for 12hours and the detail pages for 48hours or whatever. It would be also nice to differentiate between updates via API and invalidations because of time. I saw setups where it would be helpful to deactivate the automatic invalidations because of API updates and just use the timed-invalidations and vice versa. So I think it is important to have as much flexible as possible in the project to decide how to handle invalidations, because it highly depends on the project setup and the kpis of the shop. In addition to that it might also be good to define if a page should be cached. Please also keep our Cloud offering in mind, this might also be something our bigger customers need.

The rule-evaluation without caching will work the same as before (e.g. in cart or with deactivated http-cache)?

[OliverSkroblin]

So I might want to have the listings cached for 12hours and the detail pages for 48hours or whatever

👍

I saw setups where it would be helpful to deactivate the automatic invalidations because of API updates and just use the timed invalidations and vice versa.

We will only use timed invalidations. It's planned to have a separate route for invalidations and stock+price updates which immediately invalidates the http caches.

But also here, the invalidations are done via stale invalidations.

The rule-evaluation without caching will work the same as before

Not sure what exactly you mean. Sure, you can deactivate the HTTP cache completely. The rules are evaluated like before, but if you have something in the cart, it has no effect on the HTTP cache anymore

[jonashrem]

Very nice.

Make sure to add some framework or documentation how to fetch custom content via ajax which is easy to use, so that plugin vendors don't mess with the cache key

[ascheider]

@shyim Thanks! Very nice ideas. We had already some of this optimizations in the project. Customer specific prices are loaded via ajax, also things like availability of the product. We also removed $context->getRuleIds() in buildCacheHash method.
The result was very good. Very fast product page with fast variant switch and customer specific prices with higher cache hit rates.
If you introduce ESI like in shopware 5 it will be much better in my opinion. With uncached controller actions we can load prices and another uncached stuff without replacing page content via ajax.

[jonashrem]

Actually, you would prefer Ajax over ESI.

• with ESI every element increases the TTFB. With ajax you can very fast deliver the page from cache ( with also affects your SEO )
• also, when you use all volatile contend via ajax, you can cache the page itself inside the browser or on surrogate proxies like cloudflare as well.
• also you can't set cookies and headers in ESI calls

[OliverSkroblin]

We would use ESI for elements which have very high cache hit rate and are shared for multiple pages.

For content which has not so high cache hit rates or should even be loaded without any cache hit, i would prefer ajax.

For example, the navigation and footer is nearly (expect dynamic access) always cacheable because you have just the language-id + sales-channel-id.

On the other side, prices or listing filters are depending on the content which are shown and result to different cache permutation, there i would recommend Ajax instead for fast page delivery.

[jonashrem]

yes, in this case ESI of course, makes more sense. I meant I would prefer Ajax over ESI for customer-specific content which is uncacheable ( or only cacheable per customer ).

So, yes. For the navigation ESI is the way to go.

[niklaswolf]

HTTP Cache for store-api

I'm really looking forward to this as this will benefit using Shopware in a headless setup a lot!

[JulianTie]

@shyim
That sounds really good.
We are currently having a lot of problems taming the cache at a larger customer.

Could you already roughly say with which version these changes could be played out?

[OliverSkroblin]

We are already working on it. Changing the behavior is a break so a default rollout will be possible with at least 6.6.

But we also need solutions for our current rule based features

[sandermangel]

Thank you for sharing!
Couple of thoughts / questions:

• Using Ajax to include pricing: won't the hit of an uncached API request to the backend be quite heavy to retrieve prices? Especially if it's for several products shown on one page.
• How will it work with rulebuilder rules and content visibility? Many conditions are not included in the cache key
• How will this affect the cost of infrequently visited PDPs? With Object cache quite a bit is shared between pages, Relying only on http cache would mean those pages get served complete from the backend on every visit
• How will this chance the behavior for authenticated users? I didn't quite get this

[OliverSkroblin]

Won't the hit of an uncached API request to the backend be quite heavy to retrieve prices?

This is an optional feature IMO. But yes, can be quite heavy, but, right now as a logged-in customer (or with products in the cart) you also hit the whole site uncached

How will it work with rulebuilder rules and content visibility? Many conditions are not included in the cache key

That's exactly the point, this is not cache-compatible and makes nearly all sites un-cacheable right now.

How will this affect the cost of infrequently visited PDPs

PDPs => Product detail pages?
The object cache is just useful, right now, for the navigation and footer, this will be solved via ESI in the future.

[sandermangel]

Thank you for the reply @OliverSkroblin

but, right now as a logged-in customer (or with products in the cart) you also hit the whole site uncached

• true but now there is object cache to take some of that hit

That's exactly the point, this is not cache-compatible and makes nearly all sites un-cacheable right now.

• I get the idea behind that, but in practice I see that shops have only a few rules that are based on very generic conditions, which would result to maybe 6 or 7 page version at most. IMO it would still be valid to cache all this to get the right performance.

this will be solved via ESI in the future.

• this goes back to my point on hitting the backend with completely uncached events. In the past, on under platforms that I shall not name, we saw that ESI could actually have a negative performance impact

[OliverSkroblin]

true but now there is object cache to take some of that hit
Yes, however, much of this advantage is nullified because we also have to invalidate a lot when something changes.

I get the idea behind that, but in practice I see that shops have only a few rules that are based on very generic conditions, which would result to maybe 6 or 7 page version at most. IMO it would still be valid to cache all this to get the right performance.

That's only a small part of our customers. In support, we often have to debug systems that have to deal with hundreds of rules. And it's not getting less over time; quite the opposite. Rules are increasing more and more, and customers are creating more and more rules as they become more interconnected.

[DevertNet]

I am currently in the process of making my plugins compatible for 6.6 and have encountered a problem with caching. After a lot of debugging I finally found this discussion.

What is the current status of the implementation?

(6.6 RC-1; No Plugins) In my tests I have the problem that in shopware/core/Framework/Adapter/Cache/Http/HttpCacheKeyGenerator.php in the method addCookies the CONTEXT_CACHE_COOKIE is not found.
After further debugging I realised that the cookie is sometimes not sent by the browser. Probably because it is deleted beforehand by an AJAX request. I did not investigate the problem further after I found the discussion, as it may already be solved? :D

[tinect]

I see the advanced prices get limited by customer group? I would really like it! This would make any Rule-Validation for prices superfluous.
But, please keep the advanced prices 🤗 Restrict it to customerGroup, but this function is one of the key features.

[shyim]

We implemented with only particular parts with 6.6:

• Complete Kernel Refactoring, which is future-proof for systems like Roadrunner, FrankenPHP Worker Mode
• With the Refactoring, we can now use ESI tags to make parts in HTML not cached or different cached
• Delayed Cache Invalidation is now concurrency-safe with Redis

We will come up with an updated Proposal for 6.7 with more details for Pricing, Context - Cart resolving, HTTP Cache