Meine Frage nach wie man den Cache von Shopware 6 aufwärmt, mag sich blödsinnig anhören, wo man vermeintlich doch nur 1 Button anklicken muss oder ggf. die Console bemüht. Allerdings kommt mir etwas spanisch vor, wo ich mir nicht sicher bin, ob dieses Warmup so funktioniert, wie gedacht.
Für einen Test in einem anderen Zusammenhang habe ich mir die aktuelle Shopware 6 Version installiert und darin so ca. 50.000 Artikel importiert. Mal ungeachtet von meinem eigentlichen Belang hab ich mir etwas mehr erhofft. Nicht nur, dass dieser Import 3 Tage und 3 Nächte gebraucht hat, sondern der eingebaute Cache auch nicht wirklich der Brüller ist, aber sei’s drum.
Vor dem Warmup habe ich zunächst die Indizes erstelllen lassen und danach den Warmup gestartet, der aber schon nach ein paar Minuten fertig war, zumindest schien der Prozess fertig zu sein. Von den Ladezeiten im Frontend konnte man nicht erkennen, dass hier etwas aufgewärmt wurde, sodass man nicht daraus schließen konnte, dass der Shop aufgewärmt wurde.
Was also muss man besonderes machen, damit dieser Warmup auch funktioniert?
Wenn du einen schnellen Server hast, dann merkst du nicht wirklich einen Unterschied. Zumindest ist das meine Erfahrung. Hast du ein Server, der lahm ist, dann liegen da ein bis zwei Sekunden Differenz.
Es spielt beim Austesten grad keine wirkliche Rolle, ob da nun ein Shared Hosting oder ein dedizierter Server im Einsatz ist. Die beschriebene Situation bezogen auf das sonderbar wirkende Verhalten ist die Gleiche. Bedeutet, egal wo diese Test Installation grad läuft, braucht es wenige Minuten bis der Cache aufgewärmt ist und da fehlt mir schlichtweg der Glaube, dass das möglich ist. Zumal wenn man liest, dass es mitunter eine längere max_execution time braucht. Schon alleine das impliziert, dass es hier nicht nur um Minuten gehen kann.
Womöglich verstehe aber ich die Methodik nicht, wie der Shopware Cache funktioniert. Ich gehe auch bei diesem von einem HTTP Cache aus, der wie so viele andere URL basiert ist. Das würde zumindest erklären, warum der Speicherverbrauch für den Cache exorbitant hoch ist. Wenn, wie Du meinst der Cache nur dafür zuständig wäre, um Template Dateien zu cachen, bräuchte es diesen nicht. Zumal dann auch sinnloss. Es geht im konkreten Fall beim Cachen mitunter, aber maßgeblich darum die Ladezeiten dadurch zu verkürzen, dass den PHP Interpretor mit samt allen MySQL Queries obsolet zu machen, weil dadurch einerseits die größte Last entsteht und andererseits genau dadurch die Ladezeiten verkürzt werden. Mein gedachtes Wirkungsprinzip würde also genau in dieser Methodik bestehen. Wenn dem nicht so ist, dann ist es kein typischer HTTP Fullpage Cache, sondern wäre dann speicher- und nutzer bezogen. Dafür bräuchte es dann aber Arbeitsspeicher und keinen Festplattenspeicher.
Du hast Recht. Ich habe mich durch das Ladesymbol täuschen lassen. Es lädt nicht ein JSON, sondern komplettes HTML. Dann hast du mit deinen Überlegungen natürlich recht. Bei der Artikelanzahl müsste der Prozess lange durchlaufen.
Eben, also muss hier etwas nicht so laufen, wie gedacht. Es wäre deswegen wünschenswert, wenn jemand anderes noch ein paar Infos dazu hätte. Ich kann deswegen nur vermuten, dass der Warmup womöglich deswegen nicht wie erwartet läuft, weil die Artikel importiert wurden. Andererseits, und das ist das paradoxe daran, wenn ich den Cache dadurch vorwärme in dem ich einen selbstgestrickten Crawler durch alle Seiten des Shops jage, dann funktioniert das mit dem Vorwärmen. Das Gleiche natürlich auch, wenn man die Seiten per Browser aufruft.
Hast du denn den AdminWorker deaktiviert und CronJobs dafür angelegt? Kann mir vorstellen, dass das WarmUp sonst nur vorgenommen wird, solange jemand im Backend eingeloggt ist.
AdminWorker? Sagt mir zunächst mal nichts, was das sein soll?! Cron Job? Wofür, wenn es zunächst mal nur darum geht den Warmup manuell durchzuführen. Der Warmup lässt sich im Backend ja anstoßen, aber der ist nach gefühlten 3 Minuten bereits fertig, was überhaupt nicht sein kann. Über die Konsole gehts noch schneller, also überhaupt kein Warten. Nach Aufruf kommt auch gleich die Bestätigung, dass schon fertig.
Stimmt, er ist ja so schnell durch… dann ist das nicht relevant. Generell: Admin Worker ist für die Scheduled Tasks zuständig, worunter sicherlich auch das WarumUp gehört, da ja nicht alles innerhalb eines PHP-Abrufs erledigt werden kann (Zeitlimit).
Das Problem mit dem Zeitlimit habe ich nicht, aber nicht weil ich das nach Bedarf einstellen kann, sondern ich die Script Laufzeiten über meinen Webserver bei Bedarf ignorieren kann. Ich kann also selbst auf einem Shared Hosting jedes Script bis zum Sankt Nimmerleinstag laufen lassen.
Der Cache Warmup scheint nur einen object cache zu erzeugen. Nachdem ich etwas mit den Einstellungen und Redis Cache herumprobiert habe, habe ich einen Scrapy Spider (also Crawler) geschrieben der alle Links in der Sitemap anklickt, sodass die HTML Seiten wirklich generiert und im Cache abgelegt werden. Damit komme ich gecacht auf eine Ladezeit von 100ms für jede Seite. Wichtig ist noch, dass man in der php.ini realpath_cache_ttl=86400 setzt, denn scheinbar berücksichtigt der Cache nur diesen Wert als timeout. Mit allen anderen Anpassungen wie in .env SHOPWARE_HTTP_DEFAULT_TTL=86400 oder auch in framework.yaml cache.http: default_lifetime: 86400 hat sich nicht die erwünschte Wirkung gezeigt, sodass für Seiten bei denen der Cache sicher generiert war, dieser nach einiger Zeit wieder neu generiert wurde.
Bei unseren knapp 10.000 Produkt und Kategorie-Seiten dauert das generieren aller Caches somit ca. 4 Std. Wobei der Spider die Anweisung hat, nur alle 2.8 Sekunden einen neuen Link zu verarbeiten, da sonst spürbar die Experience leidet und der Shop trotz Cache nur sehr langsam reagiert. (4 Core Server, also vermutlich dann ein Datenbank Bottleneck). Der Redis Cache belegt dabei für alle Seiten knapp 2GB RAM, einsehbar mit Hilfe dieses Plugins: Tools | Shopware Store
Wie die Ladezeit mit dem Filesystem Cache ist weiß ich leider nicht, vermutlich 50-100% langsamer.
was ich bisher noch nicht herausgefunden habe ist, warum Shopware nicht in der Lage ist den Cache für ein einzelnes Item zu löschen/aktualisieren. Ich will doch nicht den komplette Shop cache der über Stunden aufgebaut wurde löschen müssen, nur um eine einzelne Seite zu aktualisieren
Seit einigen Monaten gibt es eine Page Cache Alternative für Magento, bzw. Varnish. Nun denken wir darüber nach diese LiteSpeed LScache basierte Lösung auch für Shopware 6 bereitzustellen. Allerdings fehlt es uns an Erfahrungswerten, ob es überhaupt einen Bedarf dafür gibt den Shopware Cache zu replacen. Eine Demo des Control Panels gibt es hier: