Darum schreib ich es ja. Ich schrieb auch vom Caching im Browser. Wenn der Varianten-Wechsel mit Ajax erfolgt, kann es m.E mit dem Warmup nicht gecached werden. Es muss geguckt werden warum der Ajax-Call in seiner Umgebung so lange dauert.
Hab das eben mal geprüft in shopwaredemo.de genauso, ja. Das ist nur der Browser-Cache der die Abfrage beschleunigt. Die Untervariante muss schon vorher gecached worden sein. @NextMike hat recht, der Ajax-Call ist von Shopware schon nicht so über-performant, aber dort muss (EDIT: Serverumgebung) tatsächlich angesetzt werden.
Hallo miloy,
wie habt ir das Problem gelöst?
Das wrüde mich auch interessieren …
Der erst Variantenwechsel dauert einfach viel zu lange.
Bei mir hat sich das Problem mit irgendeinem der letzten SW Updates von selbst gelöst. Inzwischen laden alle Varianten sehr schnell. Aktuell habe ich 5.5.4
Ich greife das Thema nochmal auf:
Bei einem Kundenshop dauert der Varianten-Wechsel bestimmt 11 Sek. wenn die Variante das erste Mal aufgerufen wurde. Und ca. 3 Sekunden beim zweiten, dritten, x-ten mal.
Shopware 5.6.8, Eigener Server, 16GB Ram, 16 Core, NginX, CDN, php7.4, Cache alles korrekt eingestellt.
Kann man das caching von Varianten nicht über CLI Befehle anstoßen oder sowas?
Ich greife das Thema nochmal auf:
Bei einem Kundenshop dauert der Varianten-Wechsel bestimmt 11 Sek. wenn die Variante das erste Mal aufgerufen wurde. Und ca. 3 Sekunden beim zweiten, dritten, x-ten mal.
Shopware 5.6.8, Eigener Server, 16GB Ram, 16 Core, NginX, CDN, php7.4, Cache alles korrekt eingestellt.
Kann man das caching von Varianten nicht über CLI Befehle anstoßen oder sowas?
Was betrachtest Du als Ladezeit - TTFB der HTML-Seite oder einen anderen Messwerte?
Wieviele Varianten hat ein Artikel, wieviel Artikel im Shop und wieviel Artikel mit hoher Variantenzahl?
Welche Storageanbindung nutzt Du? Wo liegen die Bilder, die Datenbank?
Nach der Hardwarebeschreibung sollte es eigentlich auch bei sehr vielen Varianten pro Artikel besser funktionieren.
Ladezeit: Wenn man die Variante tauscht, dunkelt sich der Bildschirm ab, ein loader läuft bis alles gelaufen ist. Das sind bei diesem Shop die Ladezeiten wie oben beschrieben.
Varianten-Anzahl: Unterschiedlich: Mal 3, mal 20
Storage-Anbindung? Bilder liegen auf dem gleichen webspace wie der Shop, also lokal (SSD Platte. Bilder wurden über tinyPNG komprimiert und sind nicht das Problem)
Ladezeit: Wenn man die Variante tauscht, dunkelt sich der Bildschirm ab, ein loader läuft bis alles gelaufen ist. Das sind bei diesem Shop die Ladezeiten wie oben beschrieben
Du kannst dich nicht vor deinen Computer setzen und abwarten, bis alle neuen Daten geladen sind, um eine potenzielle Fehlerquelle zu suchen. Grundsätzlich hast Du zwei Bereiche beim Laden einer Variante. Den TTFB-Wert des Ajax-Requests, der dir einen Hinweis darauf gibt, wie lange Shopware benötigt, um die Daten eines Artikels zusammenzutragen. Die zweite Komponente sind alle weiteren Assets, die anschließend geladen werden müssen, z. B. deine Bilder. Der TTFB-Wert des Ajax-Request wird sich ungefähr im Rahmen der Ladezeit eines normalen Artikels bewegen . Ist dieser zu lang, hast Du ein Problem mit der Leistungsfähigkeit deines Servers (DB oder CPU-Power) oder irgendetwas an deiner Installation bremst. Als erstes musst Du den TTFB-Wert nach Leeren des HTTP-Caches von Shopware und wiederholtem Laden messen.
Wenn Du alles manuell aufwärmen möchtest, kannst Du die einzelnen URL-„Rubriken“ bestimmen (Backend oder CLI - schau im Hilfe Text nach den exakten Parametern beim Aufruf).
Hier ist jedenfalls nicht dass dabei, was ich brauche: Shopware 5 - Tutorials & FAQs - Nutzung der CLI Befehle in Shopware
Wie kann ich die TTFB in der Konsole messen? Dachte das muss in der Konsole bei Netzwerkanalyse sein, aber da steht nichts von TTFB.
Hallo,
den TTFB könntest Du z.B. per SSH direkt auf dem Server mit curl testen:
curl command to check the time to first byte · GitHub
Viele Grüße