wir versuchen Shopware mit Elasticsearch laufen zu lassen. Dazu haben wir über die Shopware-API ca. 700.000 Artikel eingepflegt. Mit dem ES populate wird die Indizierung relativ schnell und ohne Fehlermeldung erstellt (20~30min) das darauffolgende erstellen des Caches dauert allerdings sehr, sehr lange (ca. 10~20Std). Gibt es gewisse Anhaltspunkte anhand dennen man erkennen könnte warum dies so lange dauert?
MySQL ist die meiste Zeit zu 200% ausgelastet und Elasticsearch & php/populate bleiben bei 2~3% Auslastung
Der Festplattenspeicher steigt bei der Cache-Erstellung um 8~10GB und sackt dann wieder um 6~8GB zurück.
unter var/cache/produktion_20170517… entstehen in einem der Unterordner soooo viele Dateien das ein “ls -la” in Bash das Terminal minutenlang zum einfrieren bringt (zuviele Dateien?)
Die I/O Last der SSD liegt bei 1~2% hauptsächlich durch Elasticsearch und MySQL
die Cache-Erstellung ist ja letztlich nichts anderes, als ein automatisierter Prozess, der alle verfügbaren Seiten nacheinander abruft und dadurch den Cache aufbaut. Zur Zeit ist das synchron, d.h. du kannst dir das quasi ausrechnen: 700.000 * durchschnittliche Ladezeit in Sekunden = Dauer in Sekunden.
Das Problem bei der Menge an Artikeln ist auch schlicht, dass die Standard-Cachezeiten von Shopware mit 3600 - 14400 Sekunden so gewählt sind, dass am Ende deines Cache-Aufbauens die zuerst aufgebauten Caches schon abgelaufen sind.
Jetzt davon ausgehend, dass bei dir auf dem System sonst nichts im Argen liegt, würde ich tendenziell eher empfehlen, die Cachelaufzeiten generell zu erhöhen und das Aufbauen des Caches durch eigene Logik zu besorgen. Damit könnten bspw. Caches parallel aufgebaut werden, wenngleich das die Last auf der bei dir ohnehin schon gut ausgelasteten DB noch weiter erhöhen würde. Auch wäre es denkbar, dass du bspw. primär stark rotierende Artikel “aufwärmst” und so die Gesamtmenge der aufzuwärmenden Seiten etwas reduzierst.
Schließlich sei noch gesagt: Abhängig von deinem konkreten Anforderungen kann man Shopware normalerweise auch sehr gut betreiben, ohne alle Seite “warm” im Cache zu haben.
Unser Hauptserver versucht nun seit ca 50Std die 700k Produkte einzupflegen. Die 10~20Std waren bei 300k Produkte. (Dachte nicht das es so exponentiel von der Zeit mehr wird)
Bin mittlerweile aber ein paar Schritte weitergekommen. Anbei meine Erfahrungen…
Die meiste Zeit verbringt Shopware/elasticsearch nicht damit Cache-Dateien zu erstellen sondern die Artikel-Eigenschaften in elasticsearch einzulesen.
Das einlesen der Artikel-Eigenschaften dauerte bis vor kurzem noch rund 22Sek für 100Artikel und einer Eigenschaft. Dies habe ich nun auf 6Sek verkürzen können indem wir der InnoDB einen buffer pool size von 10GB gegeben haben. Somit werden die MySQL-Querys nicht mehr in Temporäre Tabellen auf die Festplatte zwischengespeichert.
redis-server haben wir auch installiert und in der ShopWare config.php eingetragen. Die richtige Stelle?, das ging aus der Doku nicht so ganz hervor und ich weis nicht wo ich prüfen kann ob redis werkelt aber es kommt auch keine fehlermeldung…
Die größte bremse scheint die Datenbank zu sein. Hier läuft beim einlesen der Artikel-Eigenschaften auch nur ein Query zur gleichen Zeit was maximal nur einen Kern auslastet statt mehrere Anfragen gleichzeitig abzufeuern. Denke hier könnte man nur optimieren wann man die Logik von ShopWare anpasst?! „Da ist meine Erfahrung dann wohl doch zu gering“
Zur generellen Frage. Wir haben 4 Artikeleigenschaften mit ca. 70000 Einträgen. Ist dies zuviel für Shopware bzw der Falsche Ort um sowas zu hinterlegen?! In den Eigenschaften sind hinterlegt „Produkteigenheit, Modellzugehörigkeit, Komponenten-Codes, Produktmarke“. Würden die Eigenschaften nicht sein wären die Artikel vermutlich in 2~3Std komplett eingelesen.
