Hallo,
wir haben in einem Shop ca. 800.000 Artikel inkl Varianten. Leider können wir den HTTP Cache nicht aufwärmen, da der Prozess über die CLI immer abbricht…
bin/console sw:warm:http:cache -p
bin/console sw:warm:http:cache -d
bin/console sw:warm:http:cache -z
bin/console sw:warm:http:cache -y
–> KILLED
über das Backend klappt das sowieso nicht…
die Prozesslaufzeit (bevor er gekillt wird) wird übrigens mit ca. 20 Tagen angegeben…
lässt sich das irgendwie beschleunigen?
Bei einem solchen Shop macht es keinen Sinn den Cache aufzuwärmen, da die Seite schon wieder ungecached ist, bis du fertig bist.
Produkte macht wirklich nur Sinn, wenn man das in einer „normalen“ Zeit abarbeiten kann (unter einer Stunde).
Der Shop macht einen CURL-Request, wenn deien Seite bspw. ungecached 2 Sekunden braucht, dann braucht der Warmup 800.000x 2 sekunden.
Wir haben halt das Problem, dass ein Artikelaufruf oder Varianten-Wechsel 5-8 Sekunden dauert. Das ist natürlich zu lange…
Deshab war der Gedanke mit dem Cache … Man kann beobachten, dass Varianten die einmal gewechselt wurden, in Zukunft dann viel schneller sind.
ist allerdings natürlich auch blödsinn, wenn wir regelmäßig Änderungen am CSS oder der HTML-Struktur machen…
da die Seite schon wieder ungecached ist, bis du fertig bist.
wieso ungecached?
Jeder HTTP-Cache-Artikel hat eine lifetime und wenn die abgelaufen ist, wird bei Aufruf des Artikels der http-Cache wieder neu aufgebaut. Bevor du mit dem Cache Warm up fertig bist, ist die lifetime der zuerst aufgewärmten Artikel wahrscheinlich bereits abgelaufen.
Außerdem lastest Du deinen Server permanent mit dem Warm Up aus, da kannst Du diesen auch diekt über echte Kunden auslasten.
5-8 Sekunden deutet allerdings auf ein falsch dimensioniertes Webhosting hin. In der Regel sollte das < 1 Sec. sein (mit kompilierten Theme und nach erstmaligem Aufruf eine Kategorie/Artikelseite). Je nach Konfiguration des OpcodeCaches kann das auch deutlich schneller sein.
die 5-8 Sekunden beziehen sich auf Artikel/Varianten, die noch nicht vorher mal aufgerufen wurden.
Nachdem sie mal aufgerufen wurden, sind sie natürlich schneller.
wenn ich bei einem Schuh die Größe wechsle und erstmal 5-8s warten muss, ist das aber eigentlich nicht tragbar…
es handelt sich um ein AWS Hosting
Das ist zu lang. Du siehst bei dem ersten Aufruf den Du meinst die Zeit ohne http-Cache, beim zweiten dann die mit http-Cache. Es gibt jedoch noch Cachingmechanismen jenseits des http-Caches und dann bedeutet erster Aufruf nur, dass Du eine technisch vergleichbare Seite (Artikel, Variante, Katgeorie) bereits aufgerufen hattest.
AWS ist nicht gleichbedeutend mit „schnell“, eher mit gut skalierbar und jeder Menge anderer technischer Möglichkeiten. Wie schnell dein Shop damit läuft, hängt von deiner AWS-Konfiguration ab.
5-8 Sekunden ist aber eigentlich immer zu lang. Und ganz bestimmt beim erstmaligen Variantenwechseln.Entweder Du bremst mit Plugins bei den Artikeln oder hast ein falsch dimensioniertes AWS-Hosting.
Es gibt jedoch noch Cachingmechanismen jenseits des http-Caches und dann bedeutet erster Aufruf nur, dass Du eine technisch vergleichbare Seite (Artikel, Variante, Katgeorie) bereits aufgerufen hattest.
das klingt doch nach einem Ansatz. Was meinst du denn damit?
Entweder Du bremst mit Plugins bei den Artikeln oder hast ein falsch dimensioniertes AWS-Hosting.
das kann durchaus sein, wir betreuen den Shop erst seit kurzem. Nachdem optisch einiges angepasst wurde (= Theme compile, Cache leeren, etc) haben die Inhaber jetzt natürlich dein Eindruck „seit wir den Shop betreuen ist alles langsam“.
Schaue mal beim Hoster nach ob eingestellt ist, dass Prozesse nach einer bestimmten Zeit beendet werden.
@raymond das hat sich schon erledigt. einen Prozess 30 Tage durchlaufen zu lassen macht sowieso keinen Sinn.
@hth was meinst du damit
Es gibt jedoch noch Cachingmechanismen jenseits des http-Caches und dann bedeutet erster Aufruf nur, dass Du eine technisch vergleichbare Seite (Artikel, Variante, Katgeorie) bereits aufgerufen hattest.
@FloC3
Wenn du von eindimensionalen Varianten sprichst, könnte man den Variantenwechsel auch per JS machen.
Somit muss nichts extra geladen werden.
@ottscho nein es gibt 1-5 Dimensionen.
der Variantenwechsel ist aber ohnehin auf AJAX eingestellt.
Egal ob Ajax oder komplett Reload. Du hast hier halt deine Ladezeit. Reload ist die Datenmenge größer, da die ganze Seite geladen wird.
Mit Ajax wird ja nur der Teilbereich geladen.
Hättest du nur 1 Dimension, so wäre es eine Alternative.
Sprich du lädst mit dem Seitenload alle Infos deiner Varianten. Per Onclick auf die Varianten änderst du dann per JS Artikelnummer, Preis etc.
Somit hast du keine Ladezeit für den Variantenwechsel. Aber bei mehreren Dimensionen macht es vermutlich keinen Sinn.
@hth was meinst du damit
Es gibt jedoch noch Cachingmechanismen jenseits des http-Caches und dann bedeutet erster Aufruf nur, dass Du eine technisch vergleichbare Seite (Artikel, Variante, Katgeorie) bereits aufgerufen hattest.
Schau mal unter var/cache/prod… nach: Models etc. Dann gibt es noch serverseitig den Opcode-Cache. Wie lange dieser vokomplilierte PHP-Skripte aufbewahrt und wie diese vorgehalten werden (RAM/File) ist in deinem Server konfiguriert.
Habt ihr die HTTP-Minifizierung von Shopware bereits testweise deaktiviert?
Der Server sollte z. B. auch über genügend RAM verfügen, um nicht permanent swappen zu müssen, wenn Mysql z. B. temporäre Tabellen anlegt. Das sind alles Dinge, die man auch bei AWS gut und schlecht konfigurieren kann. Es kommt es auch darauf an, welche Dienste von AWS Du nutzt, um die geeigneten Parameter zu finden.
@hth leider bin ich nicht gerade der AWS oder Hosting Spezialist. Ist ja auch nicht unsere Kernkompetenz. In der Regel übernehmen das exterene Diensleister oder Managed Server. Außer in diesem Fall…
Schau mal unter var/cache/prod… nach: Models etc
und dann?
Dann gibt es noch serverseitig den Opcode-Cache.
der ist zumindest aktiviert.
Habt ihr die HTTP-Minifizierung von Shopware bereits testweise deaktiviert?
aus welchem Grund sollte man das tun? Wirkt das einer schnellen Ladezeit nicht genau entgegen?
aktuelles Setting:
aus welchem Grund sollte man das tun? Wirkt das einer schnellen Ladezeit nicht genau entgegen?
Die HTML Komprimierung ist bei ungecacheten Seiten nicht sinnvoll, da hier halt bei jeden Aufruf der Prozess gestartet wird. Die Funktion ist eher für Shops, deren Datenmenge eine sinnvolle Nutzung des HTTP Caches zulassen bzw. wo ein Warmup möglich ist.
Die HTML-Komprimierung ist überall dort ein Desaster, wo Shopware diese altmodischen Dropdowns via HTML verwendet. Dazu ein Artikel, der auch in großen Stückzahlen verkauft werden kann, und schon rennt das Script gegen die Uhr. Sagen wir mal, Dein Artikel hat ein Max von 100Stk und Schrittzahl eins. Dann generiert Shopware ein Dropdown mit 100 Elementen, also 100 Optionen - 100 Zeilen HTML-Code. Die laufen nun alle durch einen - mutmaßlich schlechten - Komprimierer, können aber gar nicht komprimiert werden! Das bläht die Scriptlaufzeit auf. Ich hatte mal im Testshop einen Artikel mit 10000Stk… Da kam dann nur noch ein 500er - wegen HTML-Komprimierung - da war dann auch irgendwann der RAM voll 
@sonic wo genau schalt ich die HTTP-Komprimierung dann aus? Ich hab nur das von CSS und JS gefunden. Eigentlich sollte das ja im Performance-Modul unter Verschiedenes sein. aber da ist es nicht
Welche SW Version nutzt du?
Performance => Einstellungen => Verschiedenes.
Ich finde es nicht wirklich gut, dass dieses Feature mit Einführung default aktiviert wurde.