wir haben unseren Shopware 6 Shop fast fertig, die Produkte wurden aus SW5.6 migriert.
Nun haben wir direkt nach der Migration (alle indexierungen sind abgeschlossen seit Tagen) das Problem, dass die Ladegeschwindigkeit der Kategorien sehr schlecht sind.
Wenn man eine Seite aufruft, dann sind 3-15 Sekunden normal.
Wenn ich die Seite direkt reloade, dann fällt die Seitenladezeit auf knapp 600ms, der Wert ist super.
Der Wert unter 1 Sekunde bleibt auch nach mehrmaligen Reload, aber dann passiert es wieder zwischendurch, das die Ladezeit auf mehrere Sekunden steigt.
Wir haben schon folgendes probiert:
Standardtemplate aktiviert
Alle Plugins deaktiviert
Alle unsere Cronjobs (meist API Anfragen) deaktiviert
Admin Worker deaktiviert
Messenger Queue über Cronjob laut Doku alle 10 Minuten
Scheduled Task auch via Cronjob alle 10 Minuten wie in der Doku beschrieben
Cache wird jede Nacht geleert und neu aufgewärmt
Leider brachte gar nichts einen Erfolg.
Hauptverantwortlich schient der TTFP Wert.
Wir haben alles vom Hoster prüfen lassen, dort sind keine Performanceprobleme ersichtlich. Unser SW5 Shop läuft mit Ladezeiten <1 Sekunde rund.
Was auch im Wasserfalldiagramm auffällig erscheint, sind die Filter. Auch diese haben wir deaktiviert im Backend, brachte auch keinen Erfolg:
Da die Seitenladegeschwindigkeit in den Kategorien hier schon das eine und andere Mal Thema waren, kann mir vielleicht jemand mit seiner Erfahrung helfen.
Wir haben derzeit die Version 6.4.10.1 laufen und aus den eben erwähnten Themen sollte das Problem mit einem früheren Update schon behoben sein.
Über ein paar Tipps würde ich mich sehr freuen, damit wir bald mit Shopware 6 an den Start gehen können!
Hört sich für mich so an, also ob der Template-Cache gebildet wird in der Zeit, in der es so lange dauert. Die Frage ist wieso. Viele Konfigurationen oder…
Wenn du den Cache aufräumst, ist die Wartezeit dann auch vorhanden?
Meinst du über php bin/console cache:clear?
Ja, das bringt keine Änderung.
In dieser Datei: all.js wird auch jedes Mal ein Filter geladen:
filter?only-aggregations=1&reduce-aggregations=1&slots=a430cacbc1504bcc8bbd98eb7348ca8c
Hier sind alle Hersteller zu finden, Preis, Bewertunge, Versandkostenfrei.
Das sind ja exakt die Filter, die man in den Einstellungen vom Layout in den Kategorien deaktivieren kann.
Nur wenn man diese deaktiviert, passiert eben nichts. Sie werden weiterhin geladen:
Auch wenn man die Filter im emplate ausblendet, sie werden trotzdem geladen.
Und dieser Aufruf braucht auch schon extrem lang. Ich denke, das dort der Flaschenhals ist, aber man bekommt diese Filter nicht weg, sie sind ja sogar im Standardtemplate immer da.
Ohne es zu wissen, ich schätze, dass die Filter im Frontend lediglich ausgeblendet werden. Auch ohne die Filter werden die Daten unter Umständen irgendwo verwendet. Ist aber nur eine Vermutung.
Nein, ich meinte Aufwärmen heißt vermutlich warmup in der console. Im Backend kann man das aber auch antriggern.
Wenn ich warmup in der Console mache, dann wird es ein wenig besser.
Nun habe ich Ladezeiten von 4 Sekunden in den Kategorien, nach mehrmaligen Reload 0,5 Sekunden, nach ein paar Sekunden dann wieder 4-6 Sekunden.
Produktseiten sind einheitlich bei 1 Sekunde.
Filter konnten wir rauswerfen, brachte auch keinen Unterschied. Jetzt ist es aber zumindest nur noch der TTFB Wert, leider, da hat man ja kaum Ansatzpuntke.
Das ist ein „normales“ Verhalten, sobald die Seite einmal generiert wurde, wird diese wirklich schnell aus dem Cache abgerufen.
Die Filter werden „nur“ ausgeblendet - es macht keinen Unterschied ob 20 Filter sichtbar oder unsichtbar sind. (Die SQL-Abfragen sind recht performant, also unter 1 Sek, jedoch sind 20 Abfragen á 1 Sek auch 20 Sek.)
Wieviele Filter / Varianten hast du?
Das eigentliche Problem sehe ich an anderer Stelle - ich war bis jetzt nicht in er Lage die Cache-Zeiten zu verändern - obwohl als TTL 86400 Sekunden (24 Stunden) hinterlegt wurden wird dieser Wert ignoriert.
Nach zwei Stunden liegen die Seiten zwar noch im Cache, jedoch werden diese neu generiert inkl. der Wartezeit.
Nur mal als Zwischenfrage: Ist der Shop in der .env Datei auf „prod“ gesetzt? Kann man ja gerne mal übersehen
Und ich würde überlegen, ob es wirklich Sinn ergibt, den Cache jede Nacht zu clearen, denn genau dieser ist ja eigentlich dazu da, die Ladezeiten zu vermeiden! Wir haben sowas bisher nicht verwendet…
Dass der Cache jede Nacht aufgewärmt erden sollte, stand irgendwo in der Dokumentation. Ich hatte anfangs auch das Gefühl, ohne, dass du den Shop dann gar nicht mehr benutzen kannst.
Hast Du bestimmte Kategorien, bei denen das Problem auftritt? Ich hab gerade durchgeklickt, ohne dass es zu krassen Ladezeiten gekommen ist, alles im Rahmen von meiner Seite aus.
Das mit der Doku ist dann natürlich so
Wir haben halt bei uns keine schlechte Erfahrungen gemacht, bisher. Und wir betreuen inzwischen auch mehrere SW6-Shops, daher mein Gedanke.
Ich kann das Problem hauptsächlich bei den „oberen“ Kategorien ausmachen, also Mode für Damen, Mode für Herren, dann die darunter Jeans für Damen, Jeans für Herren. Danach wird es besser.
Dein Gedanke ist gut. Warum ist das bei den oberen Kategorien so schlimm und weiter nach unten wirds besser…?
Bereits besuchte Seiten kommen wirklich etwas träge.
Was hast du für einen Server // Cache // Redis etc. ?
Nach „unten“ wird es besser, da weniger „Gemeinsamkeiten“ ermittelt werden müssen bzw. die Filter werden kleiner bzw. liefern schneller identische Ergebnisse. (SQL 0.1 Sek statt 0.76 Sek etc.)
Ich würde mich da an Teddy’s Antwort hängen, je höher man in der Ebene ist, desto mehr Kombinationen werden errechnet. Das trifft auch auf die Damen-Kategorie zu, da alle Produkte der Sub-Kategorien auch in der Hauptkategorie gezeigt werden. Sie sind zwar im Storefront ausgeblendet, aber von der DB geholt und berechnet werden sie ja trotzdem, solang dies nicht explizit im Code geändert wurde.
Das sieht man ganz gut daran, weil auch auf der Damen-Mode Seite ein Filter-Panel in der Sidebar ist.
Host-Europe hat im Standard OPCache aktiviert - das ist auch gut so. Mein einziger Ansatz wäre vielleicht noch DB-Cache - wenn der überhaupt vom OPCache abgekapselt ist. Ich kenn mich da leider auch zu wenig aus
Im Lighthouse Test sehe ich gerade noch, dass die Verwendung von http/1.1 bemängelt wird. Vielleicht mal mit dem Hoster über http/2 sprechen, das sollte inzwischen problemlos möglich sein. Das gibt bestimmt auch noch ein bis zwei Sekündchen.
Das könnte das Problem sein.
Aber dann muss ich mich fragen, wofür ist Shopware die richtige Software?
Wir sind mit unseren 4000 Produkten ja nun wirklich ein kleiner Fisch
HTTP/2 wird auf jeden Fall die Anzeige beschleunigen - macht den Untergrund jedoch nicht schneller.
Du denkst, dass 4000 Artikel wenig sind?
Schau dir mal die Referenzen an - da bist du bereits ein dicker Fisch.
Wenn ich mir ansehe wie lang das generieren der Feeds für Google Shopping bzw. Idealo dauert, dann ist mir klar, was „groß“ für Shopware bedeutet. (180.000 Produkte, 3 Stunden pro Feed)
Von den Cronjobs, welche Memory limits ignorieren und bis zum erbrechen ausnutzen (>96 GB) mal abgesehen etc.
Kannst aktuell „nur“ den Cache regelmäßig für die Kategorieseiten erneuern, durch einen warm:up oder Zugriff.
Für SW5 gibt es SQL Queries um das zu korrigieren, für SW6 gibt es dazu gar nichts. Hat jemand eine Idee?
SET FOREIGN_KEY_CHECKS=0
SET FOREIGN_KEY_CHECKS=1
führt leider auch zu der gleichen Fehlermeldung.
@Teddie Shopware selbst sagt immer wieder, dass SW6 für große Shops geeignet sei.
Das mit den Exporten ist mir auch aufgefallen, eines von hunderten ToDo´s auf der Liste mit SW6. Bei mir dauert ein Export keine Ahnung wie lang, er ist noch nie durchgelaufen.
Unter SW5 war der Export samt allen Varianten in 20 Sekunden fertig.
Du kannst keine Eigenschaften löschen, da du zuerst die Produkte mit diesen Eigenschaften entfernen musst - zumindest ist der FK für diese Funktion angelegt - umgedreht soll / darf das gar nicht gehen, da du dir damit auch die Produkte inkl. Varianten und deren Konfiguration zerschießt // unbrauchbar machst.
Daher musst du auch die Eigenschaften zuerst anlegen und dann die Varianten generieren bzw. erstellen.
Der SW5 Export hat bei uns schon ca. 40 Minuten gebraucht.
Ich tauche nach und nach in die Programmierung ein - bis ich für jedes Problem eine Lösung habe.
