Frontend Performance Problem, wenn Product Indexer läuft

Shopware 6 (German)
1

Wir haben ein Problem mit der Performance des Frontends, sobald der Product-Indexer arbeitet. Kategorieseiten haben dann eine Ladezeit von ca. 5 Minuten.

Wir schieben Bestandsupdates per Sync API (action/sync) und use-queue-indexing in den Shop. Diese werden dann per Supervisor getriggert und abgearbeitet (bin/console messenger:consume async --time-limit=300 --memory-limit=512M). Der Admin Worker ist deaktiviert. CPU Load und RAM gehen dann auf 20-30%, also sollte noch Luft nach oben sein.

Es können auch mal 1000 Bestandsupdates kommen. Wir müssen eigentlich auch Preise auf dem Wege aktualisieren, das kann dann schon mal 20.000-30.000 Produkte betreffen. Die Abarbeitung der Message-Queue ist auch sehr langsam.

Bei einer Tideways Anaylse sieht man, das einzelne DB Queries auf die Tabelle product sehr lange laufen, z. B. # productlistingroute::loading::search*ids > 1 Minute.

Shop: SW 6.5.2.1, ca. 45.000 Artikel inkl. Varianten
Server: VServer, 8 CPU-Kerne, 32 GB DDR4 RAM

Ist diese Verhalten normal bei SW6? Man muss doch in laufendem Betrieb Produktupdates einspielen können, ohne das die Frontendperformance zu sehr darunter leidet.

2

Shopware hat/hatte ein „Problem“ mit Varianten. Je mehr Varianten, desto größer das Problem. Gibt hier im Forum Beiträge dazu, auch Lösungsansätze. Ohne komplett alles von DAL zu SQL umzuschreiben, wird das aber wohl immer ein Bottleneck bleiben.

1 „Gefällt mir“
3

Der thread ist schon etwas alt, aber vielleicht stösst jemand noch mal auf diese Frage.

Die Lösung in unserem Fall ist, mehrere CLI worker Instanzen gleichzeitig laufen zu lassen. Wir haben z.B. 6 worker mittels Supervisor konfiguriert, dadurch wird die message queue 6x schneller abgearbeitet und der CPU dementsprechend ausgelastet.

Natürlich muss die Anzahl worker auf die verfügbare CPU Kapazität angepasst sein, es empfiehlt sich langsam nach oben zu tasten und die CPU Auslastung zu Spitzenzeiten (z.B. nach Import oder Bestand-Update Skript) zu monitoren.

4

REDIS oder RabbitMQ am laufen? Wie häufig werden die Bestands- und Preisupdates gemacht? Vielleicht überschlägt sich das auch: ist noch nicht abgearbeitet und wird wieder neu gestartet beim gleichen Artikel? Wird der Parameter --time-limit=300 --memory-limit=512M zwingend benötigt?

Ich würde erstmal: