Hallo zusammen,
ich habe aktuell massive Performance-Probleme mit meinen Shopware-Installationen (Community Edition, Shopware 6.6.10.x)
sowohl im Dev- als auch im Prod-Modus.
Ausgangslage
Ich betreibe zwei Shopware 6 Shops (Docker, PHP 8.3, Nginx, MySQL/MariaDB, Redis und Elasticsearch) und hatte anfangs gute Ladezeiten (~100 Millisekunden für die Startseite). Wir verwenden verschieden Plugins und haben Kundendaten (ca. 400) und Bestellungen (ca. 600) aus den alten Shops (Shopware 5) importiert. Bei beiden Installationen sind die Performance-Probleme aufgetreten.
Fehlersuche
Da ich in einer Kopie des Produktivshops das Problem nicht genau identifizieren konnte, habe ich mit einer neuen Shopware-Installation (ohne Plugins) begonnen und die Daten stück für Stück importiert. Beim anlegen der Produkte und Kategorien, der installation und aktivierung der Plugins konnte ich keine Performance-Probleme feststellen.
Erst mit dem Import der Kundendaten und Bestellungen traten die Probleme auf.
-
Die Speichernutzung und Ladezeit stiegen deutlich an – um ca. 1,5 GB RAM und 10 Sekunden Ladezeit.
-
Das Löschen aller Kunden und Bestellungen bringt keine Besserung.
Die Kunden- und Bestelldaten wurden ursprünglich mit dem Shopware Migration-Tool importiert. Ich habe die Daten dann per SQL exportiert und in die neue Installation importiert.
Beim Laden einer beliebigen Shop-Seite dauert der Request > 5-15 Sekunden, wobei laut Symfony Profiler der Großteil der Zeit auf folgende Komponenten entfällt:
-
kernel.controller
-
ContextResolverListener
-
sales-channel-context
-
cart-rule-loader
Fragen:
-
Hat jemand ein ähnliches Verhalten nach dem Import von Kunden-/Bestelldaten festgestellt?
-
Gibt es möglicherweise bekannte Ursachen oder Lösungsvorschläge, die dieses Verhalten erklären könnten?
Ich freue mich über eure Erfahrungen und Hinweise!
schau mal ob dieser import dir rules/regeln im backend angelegt hat - der shop mag es überhaupt nicht wenn du sehr viele rules hast (da reichen manchmal schon 50-100 komplexe Regeln)
Vielen Dank für deine Rückmeldung!
Der Import hat zwar einige Regeln angelegt, diese habe ich jedoch wieder entfernt. Im Produktivshop sind aktuell etwa 40 Regeln aktiv. In der Testinstanz habe ich diese bewusst nicht übernommen – dort sind lediglich 5 Regeln aktiv. Laut Symfony Profiler werden sogar nur 2 dieser Regeln tatsächlich geladen.
Trotzdem bleibt die Performance leider genauso schlecht, wie man auch auf den Screenshots erkennen kann.
Ohne die vollständige Profiler Ausgabe lässt sich das echt schlecht eingrenzen, man kann nicht wirklich ablesen welcher Schritt genau da so lang braucht. Wenn du einmal das vollständige Wasserfall Diagramm (Performance Metrics) zeigst sieht man es eventuell genauer.
Klar, hier ist einmal das ganze Wasserfall Diagramm:
Sieht doch schwer nach dem cart-rule-loader aus, oder interpretier ich das falsch?
hätte jetzt hier auch ganz stark die cart-rules im verdacht, testweise würde ich zunächst eine rule nach der anderen deaktivieren. Wenn das nicht hilft dann müsste man in die Tiefe debuggen wo konkret es hängt.
Ich habe alle Regeln bis auf fünf Stück entfernt, die essenziell sind und aktiv eingebunden werden.
- Cart ≥ 0: Wird in der Versandmethode verwendet.
- „Shopping Cart/Order with digital products” → Verwendet in einem Flow
- Kundengruppe 1 → Wird in den Produktpreisen verwendet.
- Kundengruppe 2
- Kundengruppe 3
Im Symfony-Debugger kann ich sehen, dass zwei Regeln geladen werden. Cart ≥ 0 und Kundengruppe 1.
An der Shop-Performance hat sich nichts geändert.
Wie kann ich das tiefer debuggen?
Auf der CLI top oder htop nutzen, Shopware im aufrufen und schauen was die Ressourcen machen. Eventuell wird dadurch klar, wo das Problem liegen könnte.
Danke für den Hinweis! Ich habe mir die Auslastung bereits mit top bzw. htop angesehen. Dabei fällt auf, dass die CPU-Auslastung beim Aufruf von Shopware auf 100 % hochgeht und auch der RAM nahe an die 1,8 GB kommt. Leider gibt mir das aber noch keinen konkreten Hinweis darauf, welcher Prozess oder welcher Teil der Anwendung diese Last verursacht und warum…
100% CPU und viel RAM bedeutet in der Regel, dass eine große Datenmenge verarbeitet wird.
memory_limit auf 512 MB setzen und schauen wo es knallt.
Geht der Webserver auf 100% oder die DB?
Der Webserver, bzw. php-fpm.
Bei einem Memory Limit von 512M:
OutOfMemoryError in vendor/doctrine/dbal/src/Driver/PDO/Result.php (line 119)
* @throws Exception
*/
private function fetchAll(int $mode): array
{
try {
return $this->statement->fetchAll($mode);
} catch (PDOException $exception) {
throw Exception::new($exception);
}
}
}
Bei einem Memory Limit von 1G:
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 41943040 bytes) in /var/www/html/vendor/shopware/core/Content/Rule/DataAbstractionLayer/RulePayloadSubscriber.php on line 53
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 41943040 bytes) in /var/www/html/vendor/symfony/config/ResourceCheckerConfigCache.php on line 163
und
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/vendor/symfony/cache/Marshaller/DefaultMarshaller.php on line 72
Dann hast du deine Bestätigung für das Diagram im vorherigen Post.
Schau dir an, was der Subscriber macht und nutze ggf. XDebug. Hast du schon einmal in der Datenbank nachgesehen, ob du vielleicht inkonsistente Datenbankeinträge bei den Regeln hast?
Alternativ kannst du auch Regel für Regel von den verbliebenen Regeln löschen und schauen, welche das Problem verursacht.
Vielleicht wurde ja eine Regel-Class überarbeitet und verursacht den Memory-Leak.
Vielen Dank für eure Hilfe!
Tatsächlich lag das Problem an Einträgen in der Datenbank: Aus welchem Grund auch immer hatten sich dort rund 1,4 Millionen nahezu identische Regel-Bedingungen angesammelt. Nachdem ich diese gelöscht habe, funktioniert jetzt alles einwandfrei.
