beim Aufruf von Einstellung -> Cache/Performance öffnete sich heute zwar schnell das Fenster. Allerdings bei Klick auf den Reiter „Cache“ erscheint erst lange Loading… und dann
0 - communication failure
Habe im Plesk nachgeschaut. Die Speicherplatzbelegung war etwa 1 GB höher als üblich. Beansprucht wurde der Speicher offensichtlich vom Ordner production_201810171014 mit 1,61 GB.
Da bei den anderen Installationen das Fenster problemlos zu erreichen war, hatte ich die Vermutung, dass das BE bei einer solchen Speichergröße das Fenster vlt nicht laden kann. Also habe ich den Ordner gelöscht.
Geändert hat sich die Situation dadurch jedoch nicht.
Der Cache wird jede Nacht per Cron gelöscht und mit einem weiteren Cronjob wieder vorgewärmt. Soweit ich das erkennen kann, ist dieses Vorwärmen seit dem 19.10. schon nicht mehr passiert - zumindest gab es keine Emailbenachrichtigung darüber.
Der Cronjob für die Löschung des Cache wurde heute Nacht mit 200 bestätigt, da könnte doch der Cache unmöglich 1,61 GB haben.
0-Communication heißt erstmal nur, dass der Prozess abgebrochen wurde. Wahrscheinlich weil er einfach zu lange lief.
In 5.5 wurde das Cache Warming ja komplett verändert. Wenn du alles aufwärmen lässt, dann brauch der Aufwärmprozess deutlich länger als in 5.4 und legt deutlich merh Dateien ab. Dafür wird dann halt auch alles aufgewärmt. Man muss sich da schon konkret überlegen, ob alles Sinnvoll ist.
Also der Production-Ordner wurde komplett gelöscht und hat sich dann selbst wieder erstellt - logisch - Größe danach 2,5 MB etwa.
Wollte den Fehler gerade wieder erzeugen um im Protokoll nachzusehen und das Fenster wird jetzt geladen. Soweit so gut. Also lag es wohl doch an der Größe des Ordners? Würde ich beruhigen, wenn es nichts schwerwiegenderes war, bei der Häufung der Probleme im Moment.
Übrigens befanden sich von den 1,61 GB Cache 1,56 GB im Ordner html.
Mit den Cronjobs kenne ich mich nicht wirklich aus. Der zum Aufwärmen des Caches hatte ich damals vom Hoster einrichten lassen und seither nichts geändert.
Er lautet: cd shopname/ && /usr/bin/env TERM=xterm /usr/bin/php bin/console sw:warm:http:cache
Ich mache die Updates immer ca. 1-2 Wochen nach Erscheinen, habe aktuell 5.5.1. Wann die 5.5 rauskam, weiß ich nicht mehr. Nehme aber an, dass es vor dem 19.10. war - bis dahin lief der Cronjob noch.
Stellt sich nun die Frage: Brauche ich den Cronjob noch oder gibt es eine bessere Lösung?
Ohne den Cronjob wäre die Seite morgens nach dem Löschen des Caches etwas langsamer, wenn ich das richtig verstanden habe.
Also unter Einstellungen - Logfile - System steht heute Nacht mehrfach die Meldung: Warm up http-cache error with shopId 1 Server error response
etwa um die Zeit, zu der das Cacheaufwärmen normalerweise startet.
Die Meldung taucht täglich auf.
Dazu ebenfalls täglich: directory /custom/plugins/SwagGoogle/Resources/views/frontend/index/index.tpl’ not allowed by security setting
Vor 5 Tagen wird noch eine angezeigt, die etwas mit dem production-Ordner zu tun hat:
RecursiveDirectoryIterator::__construct(/var/www/vhosts/domain.de/shopverzeichnis/var/cache/production_201809181442/html/en/78/a2): failed to open dir: No such file or directory
Davon abgesehen bin ich der Meinung, wenn der Cacheleeren-Cron jede Nacht erfolgreich läuft, das Aufwärmen aber nicht klappt/stattfindet, dürfte sich doch dort keine Ordnergröße von 1,61 GB ansammeln?
Nachdem gestern der Production-Ordner manuell gelöscht und der Cache NICHT vorgewärmt wurde, habe ich mir die Sache heute morgen nochmal angeschaut.
In der vergangenen Nacht wurde der Cronjob Cache löschen mit 200 bestätigt. Der Cronjob zum Aufwärmen hat keine Bestätigungsmail gesendet - wie schon seit Wochen. Dennoch hat das Verzeichnis Var heute morgen 1,47 GB, davon 1,45 GB im Ordner html.
Im Backend lässt sich das Performance-Fenster öffnen, bei Klick auf Cache lädt es sehr lange. Aber im Gegensatz zu gestern erscheint irgendwann die Anzeige. Also vermute ich, dass die Grenze irgendwo zwischen 1,4 und 1,6 GB liegt, wann sich das Fenster nicht mehr anzeigen lässt.
Es gibt hier sicherlich Shops, die deutlich größer (mehr Artikel) und deutlich mehr Besucher haben. Demnach haben die sicher einen größeren Cache, als ich. Trotzdem scheint dort die Anzeige des Performancefensters noch zu funktionieren.
Zwischen 0 Uhr heute Nacht und 7 Uhr heute Morgen an einem Freitag ist mein Shop quasi tot, da sind die Besucherzugriffe sehr überschaubar. Wie kann da ein solcher Cache entstehen? Es müssten ja entsprechend viele Seiten aufgerufen werden oder nicht?
Dieses Verhalten habe ich auch hin und wieder, also dass das Fenster sich zu tode lädt. Bei mir kommt es eigentlich immer dann vor, wenn ich mich mal 2-3 Wochen nicht um den Shop gekümmert habe und der Cache dann eben richtig „dick“ ist! Diese vielen Files packt dann wohl der Server nicht mehr und gibt Dir dann halt, weil er die Aktion abbricht, den Communication-0 Fehler aus. Einfach dann mal das Fenster aktualisieren und nochmal versuchen, dann klappts meistens - zumindest bei mir.
Auf der anderen Seite kann es aber auch gut sein, das irgednwo bei Dir was nicht richtig rund läuft und deshalb der Cache Ordner so schnell vollgeballert wird!? Bei Oxid hatte ich auch mal so ein Phänomen. Da wurden Gigabyteweise Cache Daten produziert, sodass ich nicht mal mehr via FTP den Ordner löschen konnte. Zuerst habe ich mir dann mal den Ordner umbenannt, dnach ein PHP Script geschrieben, welches den Inhalt des Ordner via Cronjob alle paar Stunden leert. Irgendwann ging mir das dann aber so auf den Sack, das ich mir die Dateien, die für den Cachheaufbau verantwortlich waren, mal genauer anegschaut habe. War alles sehr Mühsam, aber irgendwan habe ich dann den Fehler gefunden und gefixt. Da ging es letztendlich um eine Zeile falschen Code!
BTW: Diese ganze Cache Sache ist für mich schon lange ein Dorn im Auge und macht eigentlich auch immer wieder Probleme. Evtl. kannst Du diesen Problemen aber auch mit der Aufrüstung Deines Webpakets bzw. Webserver begegnen!?
Der Cache-Warmer wärmt ab 5.5 deutlich mehr URLs auf - es wäre also völlig normal, dass der Cache-Ordner um ein vielfaches Größer ist - bspw. vorher bis zu 1GB, jetzt 10GB. Den Cache-Warmer kann man entsprechend konfigurieren, das haben wir im Upgrade-Guide festgestgehalten: Shopware 5 upgrade guide
Beispiel:
1 Artikel, 2 Kategorien zugewiesen, 10 Varianten
Vorher: 1 Cache-Datei
Jetzt: ~13 Cache Dateien
Man muss sich hier schon konkret entscheiden, ob man wirklich alles aufwärmen will (würde ich nicht empfehlen) oder mit Verstand schaut, was wirklich Sinn macht (bspw. Kategorien, Produkte, Static Pages, …). Es gibt die Option alles aufzuwärmen, aber das wird sehr lange dauern (bspw. vor dem Update 200 URLs, jetzt ggf. 10.000 Urls). Das das Cache Modul da nicht fertig läd, ist auch klar. Und 1GB Cache empfinde ich pers. als nicht zu groß. Bis zu 5GB ist je nach Shopgröße ganz normal.
@Moritz Das findest Du echt ok? 5GB Cache Dateien? Ich empfinde das schon als enorm viel, aber ich bin aber auch kein Profi bzw SW Entwickler und weiß deshalb auch echt nicht, warum das so sein muss bzw. warum man das nun eben dann noch größer macht bzw so programmiert, das nun noch mehr Dateien erzeugt werden, wenn es dann aber eben doch keinen Sinn macht es so einzustellen!? Kannst du das vielleicht mal anhand eines simplen Beispiels erklären?
@Moritz Das findest Du echt ok? 5GB! Cache Dateien? Ich empfinde das schon als enorm viel, aber ich bin aber auch kein Profi bzw SW Entwickler und weiß deshalb auch echt nicht, warum das so sein muss bzw. warum man das nun eben dann noch größer macht bzw so programmiert, das nun noch mehr Dateien erzeugt werden, wenn es dann aber eben doch keinen Sinn macht es so einzustellen!? Kannst du das vielleicht mal anhand eines simplen Beispiels erklären?
Die Anzahl der Dateien kannst du immer konfigurieren. Der HTTP-Cache ist ein Full-Page Cache, es wird also für jede Seite die abweichend von der Originalseite ist, eine eigene Cache-Datei angelegt. Zusätzlich wird der Cache auch nach dem im Cache-Modul definierten Zeiträumen invalidiert und neu erzeugt.
Nehmen wir als einfaches Beispiel eine Artikeldetailseite:
Aufruf über eine Kategorie Der Domainname meinshop.de steht zum Verkauf. (Breadcrumb anders -> neue Cache-Datei, kann man in den Grundeinstellungen deaktivieren, dass der Parameter angehängt wird)
andere Kundengruppe mit anderen Preisen -> neue Cache Dateien für alle oben genannten Cases
Dann werden im Standard die Seiten mehrfach pro Tag invalidiert. Entsprechend werden wieder neue Cache-Dateien angelegt. Wenn ich viele Varianten, viele Kaetgorien und viele invalidierungen habe, können sich da eine große Menge an Dateien ansammeln. Daher kann man das alles einstellen und muss das auch sinnvoll hinterfragen, was Sinn macht. Aber für die Seite ist das auch wesentlich schneller als alle Inhalte per Ajax abzufragen, da sonst jeder Aufruf für individuelle Inhalte auch eine DB-Last erzeugt.
Also konkret:
Überprüfen ob man den ?c-Parameter braucht (SEO/Router-Einstellungen > Kategorie-ID anhängen)
Überprüfen wie oft am Tag der Cache neu geschrieben werden soll (Caches/Performances -> HTTP-Cache)
Überprüfen welche URLs man auch wirklich aufwärmen will
In der Regel ist Speicherplatz günstig, daher kann man besser viele Dateien auf dem Server ablegen, die dann schnell ohne DB/PHP-Last ausgeliefert werden können, als für jede Seite zusätzliche DB-Abfragen zu machen. Das ist ja auch der Sinn von einem Full-Page-Cache. Wenn man natürlich jede erdenkliche seite Cachen lässt, kand as auch viel sein.
Danke für Deine Erklärung. Mir ist schon klar, das Cache wohl der Performance eine z.B Webshop dient, ob nun Browsercache oder Webservercache. Und klar, Speicherplatz ist in der Tat günstig und die 5GB jucken mich auf dem Server eigentlich nicht wirklich, klar. Nichts desto trotz verschlingt mehr Cache natürlich auch wieder mehr Hardware Resourcen sowie mehr Zeit, den Cache zu erstellen.
Ein kleiner Cache ist demnach eigentlich immer schneller. Aber klar, in dem Fall muss man eben, so wie Du es erklärt hast, das alles mal kontrollieren bzw. einstelllen,was man wirklich gecached braucht, damit das System eben nicht kollabiert. Und wie gesagt, ich kann da nicht wirklich mitreden, aber ich weiß auch echt wirklich nicht, ob der Sinn von Resourcen ist, sie zu verschwenden, nur weil wir sie haben!? Ein Ansatz in Richtung resourcenschonend fände ich da schon besser, weiß aber nicht, ob das technisch immer alles so machbar ist…?
Es geht ja darum, dass es grundsätzlich schneller ist eine gecachete Seite aufzurufen, als das diese erst durch PHP / MySQL erzeugt werden muss. Wie Moritz sagt kann man daher bei den heutigen Speicherpreisen den Ansatz verfolgen, möglichst alles zu cachen und dieses dann schneller auszuliefern. Nimmt man jetzt nur selten Änderungen an Artikeln oder anderen Content vor, ist der Aufbau auch kein Performance-Killer, da er nicht kontinuierlich stattfindet.
Wir bieten ja die Möglichkeit anhand von Parametern beim Ausführen des CLI Befehls für den Warmup selbst zu entscheiden, ob man nun mehr im Cache liegen haben möchte oder nicht.
Mehr Inhalt cachen bedeutet halt automatisch mehr Ressourcen, da kann man technisch nichts machen.
Verstehe ich das so richtig:
Vor sw 5.5 wurde die Seo-URL aufgewärmt, seit 5.5 nun auch die URLS mit allen möglichen Paramatern. Daraus resultiert ein großer Cache, wenn man alles aufwärmt. Der große Cache ist aber bei ausreichend Speicherplatz kein Problem, sondern beschleunigt die Seitenaufrufe für die Besucher.
Da es bei mir Änderungen immer gesammelt in größeren Zeitabständen gibt, würde es ausreichen, wenn ich danach den Cache manuell leere und wieder aufwärme.
Wenn ich einen kleineren Cache möchte, muss ich also entscheiden, welche URL bzw. Parameter ausgeschlossen werden. Wo die zu ignorierenden Parameter eingetragen werden müssen in der default.php habe ich gefunden.
Was müsste ich dort z.B. ergänzen, wenn ich folgende URLs ausschließen möchte:
Artikelvarianten
Hersteller
Blogseiten
Shopseiten
Also was müsste für die genannten Seiten zwischen ‘…‘,?
