uns hat es die komplette Datenbank lahmgelegt. Nach Analyse von unserem hoster wurde uns folgendes mitgeteilt:
Wie besprochen, sende ich Ihnen hier die Qureys, welche die Betreffende DB lahmgelegt haben:
13423523 p223246 172.17.37.104:49733 usr_p223246_4 Query 3417 statistics SELECT SQL_CALC_FOUND_ROWS product.id as __product_id, variant.id as __variant_i
13425440 p223246 172.17.37.104:53263 usr_p223246_4 Query 3023 statistics SELECT SQL_CALC_FOUND_ROWS product.id as __product_id, variant.id as __variant_i
Leider können wir hiermit gar nichts anfangen, wollen aber natürlich verhindern, das so etwas nicht noch einmal vorkommt.
Hat einer eine Idee, wie wir herausfinden können, woher dieser Aufruf kam? Ob von einem Plugin oder ähnliches? Die Plugins sind ja verschlüsselt und man hat hier ja keine Einsicht um vllt die Fehlerquelle zu finden.
das könnte diese Stelle sein: \Shopware\Bundle\SearchBundleDBAL\QueryBuilderFactory::createProductQuery
Die wird benutzt, um die Produktlisten zu generieren / Kategorieseiten. Entsprechend kommt das bei Suchen, Filterungen und normalen Listings zum Einsatz. Ob das ein reines Core-Problem ist, ist schwer einzuschätzen, da dies auch eine übliche Stelle für Erweiterungen ist. Entsprechend sollte hier zunächst geprüft werden, ob ggf. Plugins aktiv sind, die an diesen Stellen eingreifen. Sowas kann beispielsweise schon durch Funktionen wie „Filter direkt ausführen“ passieren, da dann die Anzahl der Filter-Anfragen massiv steigt.
Weiterhin skaliert das insgesamt in MySQL nur in gewissen Grenzen, weswegen wir ab bestimmten Artikelmengen die Nutzung eines Elasticsearch-Suchservers empfehlen. Je nach Last, Server-Konfiguration und Variantenanzahl kann das ab Artikelmengen um die 80.000-140.000 Artikeln erforderlich sein.
Eine weitere Maßnahme stellt die Prüfung des Performance-Moduls dar: Hier können bestimmte Funktionen deaktiviert werden, die sich negativ auf die Geschwindigkeit auswirken. Das sind meines Wissens insbesondere Preis-Filter und -Sortierungen. Da könntest du einfach mal die Optionen in dem Modul durchgehen und möglicherweise nicht benötigte Funktionen deaktivieren.
Die wird benutzt, um die Produktlisten zu generieren / Kategorieseiten. Entsprechend kommt das bei Suchen, Filterungen und normalen Listings zum Einsatz. Ob das ein reines Core-Problem ist, ist schwer einzuschätzen, da dies auch eine übliche Stelle für Erweiterungen ist. Entsprechend sollte hier zunächst geprüft werden, ob ggf. Plugins aktiv sind, die an diesen Stellen eingreifen.
Welche Möglichkeiten habe ich denn, um die Plugins zu testen? Die sind ja alle verschlüsselt und kein Quellcode einsehbar.
Weiterhin skaliert das insgesamt in MySQL nur in gewissen Grenzen, weswegen wir ab bestimmten Artikelmengen die Nutzung eines Elasticsearch-Suchservers empfehlen. Je nach Last, Server-Konfiguration und Variantenanzahl kann das ab Artikelmengen um die 80.000-140.000 Artikeln erforderlich sein.
Okay. Dann sollten wir hier keine Probleme mit knapp 3.000 Artikeln haben.
Eine weitere Maßnahme kann das Performance-Modul sein: Hier können bestimmte Funktionen deaktiviert werden, die sich negativ auf die Geschwindigkeit auswirken. Das sind meines Wissens insbesondere Preis-Filter und -Sortierungen. Da könntest du einfach mal die Optionen in dem Modul durchgehen und möglicherweise nicht benötigte Funktionen deaktivieren.
In dem Performance-Modul ist unter Filter nur der Hersteller und der Eigenschaften Filter aktiviert. Sortierung und Preisfilter sind hier gar nicht aktiv. Und den Herstellerfilter könnten wir auch noch raus nehmen.
bzgl. der Plugins: Das sollte sich ja schon aus dem Einsatzzweck ergeben. Gefragt ist halt alles, was in Listing / Filterung / Suche eingreift, würde ich erstmal denken. Habt ihr da was?
Ansonsten müsste man echt nochmal über die Dimensionierung des Datenbanksystems nachdenken. Es ist schon so, dass die Abfragen nicht ganz trivial zu berechnen sind - das Ausmaß, das du beschreibst, erscheint mir aber doch etwas heftig. Da gibt es hier ein paar Tipps: Shopware 5 performance guide for system administrators
Besonders die innodb_buffer_pool_size sollte passend gesetzt sein.
Da wir noch Shopware 5.1.6 mit einem Shopware 4 Template laufen haben, benötigen wir das Plugin noch und augenscheinlich funktioniert es auch korrekt. Zumindest werden die Produkte so nachgeladen wie unter Shopware 4.
Bei der Datenbank müsste ich dann selber einmal nachfragen. Die Datenbank liegt bei Mittwald (MySQL 5.6 - SSD). Sollte ja eigentlich recht schnell sein. Bin jetzt aber davon ausgegangen, dass das bei Mittwald schon alles für Showpare optimiert ist, wenn man das System über die Agenturtoolbox laufen lässt.