Hallo, wir haben EINE Kategorie im Shop, deren Aufruf extrem lang dauert. Sprich das Listing.
Alle andere laufen problemlos. Was kann das für Gründe haben? Da sind nur 50 Artikel drin. 6 Subkategorien.
Aber relativ große Anzahl Filter bzw. Filteroptionen … kann es daran evtl liegen? Außerdem gibt es relativ viele Varianten (50-400) pro Artikel … kann das auch ein Grund sein?
Beim 2. Aufruf ist die Ladezeit dann viel schneller…
und ja, Shop läuft in produktiv-Modus
Niemand eine Idee?
Wie wärs mit Firefox/Chrome Developer Tools und Network Tab und schauen, was so lange dauert?
„Beim 2. Aufruf ist die Ladezeit dann viel schneller…“ > Klingt nach leerem Cache.
Ein Profi würde den xDebug-Profiler anschmeißen (oder zur Not jenes von Symfony nehmen) und die MySQL slow query logs auf fehlende Indeces prüfen. Bekommst Du davon etwas hin? Ansonsten: wärme den Cache vor, teile die problematische Kategorie auf mehrere auf, oder vermeide (Preis-)Filter, die auf die Varianten schauen müssen.
@ChocoSW da helfen die Developer-Tools wenig, denn die zeigen auch nur, dass der Seitenaufruf langsam war bzw. wie lange er gedauert hat. Das weiß ich aber auch so …
@euroxid kanns wirklich am Cache liegen? Ein Warmup sollte ja nichts anderes sein, wie wenn ich als User die Kategorie öffne oder? Denn danach gehts ja schnell. Allerdings halt nur für gewisse Zeit … der Cache geht also nach gewisser Zeit verloren und muss neu aufgebaut werden. Gibts so eine Funktion in SW6? Glaube nicht.
EDIT: irgendwie kann es auch am Cache nicht liegen… hab ihn grad mal gelöscht und wollte sehen, ob die Kategorie dann wieder lange braucht zum Laden. Aber es ging ganz schnell. Komisch…
Hi,
das frage ich mich schon länger bzgl. dem Cache.
Woher kann man ermitteln oder ersehen, ob die Seite nun vom Cache geladen wurde oder nicht.
Evtl. hat ja jemand anders oder ein Bot die Kategorie zwischendurch aufgerufen und die Seite ist im Cache.
In Shopware5 war das einfacher, da lag wirklich für die Seite eine Datei im Cache, bei Shopware 6 ist das kompilizierter.
Das Cache-Alter kann man in den Header-Daten des Requests sehen:
In der .env habe ich folgende Einstellung bzgl. der TTL gefunden:
Ob beim Cache-Warming etwas schief läuft kann man sehen, indem man in der Konsole den bin/console http:cache:warm:up ausführt, und dann den bin/console messenger:consume -vvv
Bei Fehlern und Warnungen sollte man da was angezeigt bekommen.
Was mir bei uns aufgefallen ist:
Irgendetwas bei unserem Cache-leeren/Cache-Aufwärmen-Prozedere erstellt einen neuen Cache-Unterordner (prod_######), lässt alte Ordner aber drin, was uns Gigabyte an Cache-Daten beschert hat. Hier könnte man die Datengröße mal prüfen:
du -sh var/cache/
Ein Löschen der überflüssigen Ordner hat unser System sehr beschleunigt…
Hi,
ja, das mit dem Age hatte ich gesucht.
Wobei im Prinzip Age =0 oder Age = 1 bedeutet, daß ich Pech hatte und die Seite nicht im Cache war,
wenn ich das richtig interpretiere.
Ja, die Cache-Verzeichnisse kenne ich, blöd auch, daß die Cache-Ordner wirklich riesig sind.
Hoffe, daß Shopware da noch was verbessert, zumindest hatten die das mal auf dem Plan.
Weiß Du zufällig, ob bei Änderungen im admin z.B. am Produkt der Cache für die Produktseite auch wieder neu aufgewärmt wird?
Bzw. in Shopware 5 konnte man z.B. beim ändern eines Produktes über die Rest-Api auch den Cache gleich mit aufwärmen,
gibt es sowas in Shopware 6?
Wie macht ihr das mit dem Cache neu aufwärmen, irgendwann ist die Zeit ja abgelaufen, dann hat der erste, der eine Seite aufruft ja das Pech,
daß der Aufruf langsam ist, wäre das ein Bot, wäre das sauschlecht. Die Wahrscheinlichkeit ist ja nicht klein.
Gruß,
Werner.
Wir haben das Ordner Problem gelöst, indem wir im Cron vor dem Cache-Aufwärmen alle Cache-Ordner entfernen (alles in ein Shellskript gepackt).
Das kann im Entwicklungsprozess richtig heftig werden. Soweit ich mich erinnere, war die gesamte Installation irgendwann 59GB groß…
„Weiß Du zufällig, ob bei Änderungen im admin z.B. am Produkt der Cache für die Produktseite auch wieder neu aufgewärmt wird?“
Kann ich leider nicht sagen. Ich weiß nur, dass beim Cache-Aufwärm-Befehl die Enqueue-Tabelle mit Messages gefüllt wird, die dann durch den Messenger abgearbeitet werden.
Die Cache-Funktionen haben wir mit Cronjobs gelöst. Der Messenger wird dort mit definiertem Timeout regelmäßig angestoßen, und davon autark regelmäßig durch einen weiteren Cronjob der Cache-Aufwärm-Befehl abgesetzt.
Für einzelne Bereiche hab ich auch einen wget-Befehl ausgeführt, der den Bereich dann crawlt (weil dieser Bereich aus einem Plugin kommt, und es dort Probleme mit dem Cache-Warming gab).
Hi,
okay, danke für die Info’s.
Ganz schön kompliziert irgendwie…
Hoffe wenigstens, daß man bei Änderungen der Produkte (z.B. über die API) irgendwie die Möglichkeit hat, den Cache gleich aufzuwärmen,
also nur für dieses eine Produkt.
Wenn man bedenkt, daß unser jetziger Shop (kein Shopware) ohne Cache nicht soviel langsamer ist, als Shopware mit Cache …grübel…
Gruß,
Werner.
Ich würde mit dem aufwärmen etwas aufpassen, ob dies so viel bringt. So schnell könnt ihr gar nicht schaun, fliegen eure Seiten wieder aus dem Http-Cache raus.
Unserer Erfahrung nach wird der gesamte Http-Cache (also wirklich jede Seite im Http-Cache) invalidiert, wenn
Der Grund ist, dass alle Seiten im Http-Cache mit extrem vielen so genannten Cache-Tags versehen sind.
Ich sehe hier dringenden Handlungsbedarf bei dem konzeptionellen Problem und hoffe, dass Shopware möglichst bald drastische Verbesserungen bringt!
Dazu gibts bereits Tickets und Shopware weiß bereits Bescheid: https://issues.shopware.com/issues/NEXT-10094
Hallo,
vielen Dank für die Info’s, das sind sehr, sehr nützliche Informationen, die ich mir eigentlich von Shopware in der Doku erhofft hatte…irgendwann.
Also wann genau einzelne Cache-Teile invalidiert werden, kann man das selbst gezielt anstossen usw.
Wir schreiben einen eigenen Import, da wäre es auch wichtig zu wissen, wie man z.B. beim Update nur den Teil des Caches invalidieren kann,
der von diesem Produkt abhängt, das ging in Shopware 5 und war dort gut dokumentiert.
Bei Shopware 6 habe ich das hier gefunden:
ist mir aber noch nicht ganz klar, wie ich das anwenden kann. Sonst weiß ich leider nicht, wie man gezielt nur einen Teil vom Cache invalidieren kann.
Das aber der gesamte Cache invalidiert wird bei diesen Aktionen wie oben beschreiben, ist natürlich furchtbar schlecht, zumal das Aufwärmen ja auch
lange dauert bei vielen Produkten und Kategorien und auch sehr groß wird (mehrer GB).
Ohne Cache, ist Shopware mit vielen Produkten (100.000) und Kategorien (> 1000) für meinen Geschmack zu langsam.
Zumindest gut, daß Shopware an dem Problem arbeitet bzw. das als Problem ansieht 
Gruß,
Werner.
Ich habe unter Shopware 6.4.14.0 das gleiche Problem mit einer Kategorie mit vielen Unterkategorien (ca 300). Der Aufruf ist sehr langsam. Danach geht er aber schnell, das hält aber nur für eine bestimmte Zeit an, danach wird der Aufruf wieder langsam.
Gibt es da mittlerweile eine Lösung für?
Moin, wir hatten das Problem auch. Fündig wurden wir an drei Datenbankabfragen beim Aufruf der Kategorien.
Letzlich geholfen hat nur, den Hoster zu wechseln auf einen für Shopware eingerichteten Server mit Redi und ElasticSearch.
Das war die Lösung.
Wir hatten da damals auch 3 Monate alles mögliche probiert, es funktioniert nicht.
Was hast du für ein Hosting?
Wir sind bei Profihost. Redis sollte möglich sein. Ich werde unseren Hoster diesbezüglich mal kontaktieren und bis dahin als workaround per Skript regelmäßig die betreffende Kategorie aufrufen.
Wie kommen denn diese vielen Unterkategorien zustande?
Wir haben für jede Marke eine Unterkategorie