Wir löschen in unseren Shopware-Installationen einmal pro Nacht den HTTP Cache via Shopware_CronJob_ClearHttpCache. Dabei werden die Cronjobs direkt über die Console mit bin/console sw:cron:run ausgeführt. Die Ergebnisdaten des Cronjobs sind Cleared HTTP-Cache , also positiv. Allerdings sind im Verzeichnis var/cache/production_xxx/html/ immernoch Dateien und Ordner von vor 2 oder 3 Wochen zu finden. Deshalb meine Frage, was macht der Cronjob Shopware_CronJob_ClearHttpCache eigentlich bzw. wie kann ich im Dateisystem feststellen, ob dieser tatsächlich erfolgreich war?
Das bringt mich zu einem weiteren Verständnisproblem: Was sind die Unterschiede dieser Funktionen:
clear_cache.sh wirft den kompletten Ordner weg, nicht nur den HTTP-Cache und sollte nur als Rescue-Script genutzt werden. Das verursacht zusätzliche Datenbank-Last (bspw. für Models) die man nicht braucht. Im Backend wird auch bspw. der Konfigurationscache und der Template-Cache mit gelöscht und nicht nur der HTTP-Cache. Ist also nicht identisch mit dem Cronjob. Aus dem Kopf müsste sw:cache:clear identisch mit dem Shopcache leeren im Backend sein. Der HTTP-Cache Cronjob leert nur den HTTP-Cache und nichts anderes.
Feststellen kannst du eigentlich nur, ob der Ordner HTML im Cache-Verzeichnis nach dem Cronjob-Lauf kleiner ist.
Vielen Dank für die schnelle Antwort. Diese Erklärung macht Sinn.
Hast du auch eine Idee wieso trotz täglichem positiven Ausführen von Shopware_CronJob_ClearHttpCache im html Ordner noch jede Menge alte Dateien rumliegen? Diese müssten doch eigentlich gelöscht werden, richtig?
Alte Dateien weiß ich nicht. Soweit ich es in Erinnerung habe löscht der Cron nur Dateien, keine Ordner. Müsste ich aber auch erstmal testen. Glaube da gab es irgendeine Eigenheit.
Ändert sich denn nach Ausführen des Cronjobs grundsätzlich etwas im Performance Modul (Größe des Reverse Proxys)? Falls nicht, kann hier auch das Access Log des Servers helfen, da Shopware bei Durchführung des Crons einen globalen BAN Request auslöst. Hier sollte man im Access Log schauen, welcher Status Code zurückgegeben wird (der korrekte Code müsste 200 sein).
Vermutung: Der Server sendet den BAN Request über seine externe IP-Adresse (steht auch im Access Log), also nicht über die 127.0.0.1 (deswegen blockiert Shopware diesen Request, sonst dürfte ja jeder den Cache löschen). Gibt es dafür eine Einstellung in Shopware oder muss das auch auf Seiten des Hosters geregelt werden?
Okay…Problem gefunden. Es liegt an NGINX und betrifft wahrscheinlich viele Leute die NGINX und den Shopware_CronJob_ClearHttpCache benutzen. NGINX hat Probleme mit PUT, PATCH, DELETE, OPTION, TRACE und auch BAN Requests wenn diese an / gesendet werden. Wenn ich die Datei also shopware.php mit angebe, dann geht der Request durch und der Cache wird tatsächlich gelöscht.
Der Redirect wurde übrigens dadurch verursacht, dass Shopware den BAN Request an http statt https gesendet hat. Dadurch wurde der 301 Redirect an https gesendet. Aus dem BAN Request wurde so ein einfacher GET Request.
Also direkt zwei Probleme weshalb das nicht funktionieren kann. Wir verzichten nun auf den Shopware_CronJob_ClearHttpCache und nutzen stattdessen sw:cache:clear über einen eigenen Cronjob.
Ich habe upstream eine Lösung vorgeschlagen. Darin wird der BAN Request innerhalb Nginx umgeschrieben auf die matching location die zu fastcgi weiterreicht. Wenn jemand Zeit findet die Lösung hier oder im github PR zu bestätigen, findet diese unter Umständen weitere Verbreitung.