Scalling shopware storefront

[OliverSkroblin]

Effort: high

Description

Our focus in the next terms, will be among other things to optimize the performance of the system for high load scenarios.

In this regard, we will need to make some adjustments to the current storefront, store API and feature implementations.

Exact details of these adjustments are not yet completely foreseeable, as they will result from load test scenarios.

In many cases, however, it is not enough to refer to the Http cache, as a page could be invalidated again quite quickly.

For solving this problem, we have already discussed and evaluated different approaches:

• In some cases, we want always-hot caches (really easy routes).
• In some cases we want to implement a separate (mutable) memory storage (mongodb, etc) that contains read-optimized data
• In some cases, we want to reduce DAL usage and return to simple sql or remove BIG entity objects for the storefront.
  • For example, hydrating of 3000 property options will always be slow.

Advantages

• We can host large projects in an even better way.
• Better scaling of the application
• Reduced resources for cloud products

Break strategy

We will implement the breaks and optimizations in the 6.4 track, but hide the changes behind the major feature flag v6.5.0.0. With the major release, we will enable the feature flag and remove the conditional breaks in the code.

[janbuecker]

It absolutely makes sense, to reduce the DAL usage and remove load from the application. 👍 I don't mind which storage you end up querying. :-)

From a cloud perspective, you'll never beat an HTTP cache on edge nodes, located around the world and near the customers, with (no)sql databases and/or cache stores like redis etc.
Because of that, I think that it could make sense to think about how to improve the HTTP cache and counter its downsides. I can imagine, that we could implement a cache switch that basically works like the Elasticsearch index switch in Shopware to prevent that users run into a cold cache and overwhelm the server.

[OliverSkroblin]

You are absolutely right. The HTTP cache is also an important part of our software and we will of course continue to expand and improve it. We have only heard from large customers that the HTTP cache is not a solution for them, because they play out a lot of individual content.

Therefore we would like to work on a solution that if the HTTP cache should not work in such scenarios, the system still scales as best as possible and does not collapse due to the database load alone.

This "proposal" is not meant to make it seem like "HTTP cache is bad - we need something else", either :"caching is not the solution for everyone and our system should scale reasonably well without a cache".

[ssltg]

Are you planning this layer to be in the storefront or in the store-api?

[janbuecker]

When designing the new implementation, please invite @jenskueper and me to the meeting to give you some insights of how we work with a multi-tenant environment and have special requirements to not overfill our memory storage. Maybe we can find a good solution for both worlds.

[OliverSkroblin]

@ssltg we plan detailed performance benchmark in the next terms. Based on the results, we will talk about the concret implementations.
But i think that most of the optimizations will be done on the store api layer, which has an direct impact to the storefront too.

@janbuecker 👍

[kleinmann]

Not sure if this was already considered in the past: Have you thought about fragment caching to mitigate downsides of a "full-page" HTTP cache, but still allow for dynamic/individual content?

I'm aware that a usable implementation without performance surprises can be difficult (remember sub-requests with {action} in Shopware 5?). Fragment caching could allow for specialized performance optimizations by increased hit-rates and reduced permutations of the same element.

[aragon999]

Additionally to improve the loading of the entities, maybe there would be room for a more general concept, namely "enriching" entities. Something which is currently in a special case implemented for the sales channel entities.

I could also imagine this concept would be useful as it was done in Shopware 5 with the listProduct and product. As far as I have it in my head currently in Shopware 6 this is solved by different routes, which is in principle fine, but it would be nicer (and it would probably be used more often) to have this, generalized, on the entity level. Additionally all related entities should be "enriched" into the same state (which could be that it is not implemented, and there is no change).

If such an idea is reasonable, we can discuss more.

[OliverSkroblin]

@kleinmann in shopware 6 we have deliberately decided against esi tags, because they have caused a lot of problems with shopware 5. We even decided not only consciously against it, with the new HTTP cache this was even a hard requirement that we should implement it without esi tags 😉

@aragon999 I am still not sure what exactly you are getting at. We had the concept of listProduct and detailProduct at the beginning of shopware 6 in the alpha phase and it caused incredible problems due to the criteria objects. With the future refactorings we want to become even stricter again with regard to the data structures in the storefront.

We want to introduce a mode, whereby the data for the client (storefront in our case) is always optimally indexed in the Store-API layer. The Store-API would therefore no longer be so dynamic, but would be optimized for high load scenarios. The mode would of course have to be configurable for each system.

[aragon999]

@OliverSkroblin so what my proposal aims at is to reduce the data inside the entities to what is needed in different places.

As an example I referred to the list-product and detail-product, but there are probably also other places where such a concept could be useful. The current implementation of the sales-channel entities falls from my perspective in the same category, i.e. you have a base entity which you enrich with additional information when loaded for the sales channel.

So my idea was to implement a system which can do this in a more general way, not only restricted to those two cases. There are of course different ways one could thing of implementing it.

One way could be that one can add something like a tag to the criteria object, for example the sales-channel tag could be set for all sales channel routes. For each tag one can (optionally) register logic which takes care for that entity such that this is in the correct state for this use case. It should probably also be possible to tag associations individually.

Currently for plugins it is hard to capture all the cases and modify the criteria object for that particular use case, so what often happens is that one does not distinguish in plugins, and loads for example always all the data which is actually only required on the detail page, and only a portion of the data is needed for the listing.

Not sure if this feature would contradict some other performance optimizations, if the drawbacks are of course too much, the idea is not useful :)

[kleinmann]

@OliverSkroblin ESI tags are just one of the ways to approach this 🙂 Are you saying fragment caching as a concept is not something you'd want to consider?

[niklaswolf]

Love to hear that the improvements are meant to be in the store-api layer, as this also would benefit headless channels enormously!
Store API requests are often POST requests on a technical level (to be able to send bigger payloads for criteria), even if the purpose is more or less to GET data. This breaks the FPC usage at the moment, so I'd love to see improvements on the store api level!

[OliverSkroblin]

@kleinmann okay i misunderstood you, no fragment caching we already do now, e.g. on store-api level or the context factory, etc. But ESI is something we explicitly did not want implemented 😄.

@aragon999 The various Store API routes are intended for this concept. The detail route defines which data is responsible for a detailed representation of a product. And the product-listing route, how products have to be loaded into listings for the store. Currently the only problem is that the client decides which data it wants to have, which is the wrong approach in my opinion, because this can lead to too many permutations on data level. If we would define now, how a list-product should look like, we have again the problems that in other projects a list-product should look different. Therefore I would rather drive the approach that the routes define the appropriate data representations, and for high-load scenarios these are accordingly "warmed up".
So you are not so wrong with your idea of different data representation, I would just realize it differently than in shopware 5

[JoshuaBehrens]

@niklaswolf Your example sounds like it perfectly matches the QUERY HTTP verb mentioned in this proposal. I assume we don't get it in symfony 6 like the HEAD verb ... right? This would probably be a huge benefit for your case as well.

@OliverSkroblin @kleinmann so would you discourage the usage of twig cache blocks as well? I see that when I start to use these cache blocks around e.g. the main navigation I don't gain a lot as the heavy lifting of sorting and tree-building the navigation will be done anyway. ESI would also be a benefit here as one could "outsource" loading navigations into a separate "widget".

@OliverSkroblin @aragon999 regarding list products. I understand that warming caches is nice, but it sounds like we have to warmup everything to have everything fast. When the application would be fast instead we don't need warm caches. E.g. the product suggests could just be a suggestion entry. But AFAIK these are also fully featured products. The grain of detail is just within the loaded assocations but all in all I "just" need a price(-range) some human readable names and a picture. Minimizing load there is an optimization that you will go because you optimize for a use-case. Optimize for use cases is I think the right thing. An ORM is e.g. bad at being perfectly generic. Because it can't be perfectly generic. Best example is the Elasticsearch indexing. We already lost the DAL as single source of truth there for a specialized improvement. This already is the list-product we are looking for. It is just the "elasticsearch-product".

[vitalijalbu]

Hi guys, new in shopware. I’d like to create a multi language headless ecommerce using react (nextjs).
Do you usually manage frontend with admin page builder or manually create sections and blocks in frontend?.
Cannot understand how it works and how to start…
Thanks.

[OliverSkroblin]

See: #3613