Seitencache täglich löschen

[Troy]

Danke für den Link!

Hat jemand zufällig ein Snippet bereit, wie ich folgende beiden Befehle alle 24 Stunden ausführen kann?

vendor/bin/contao-console cache:clear --no-warmup
vendor/bin/contao-console cache:warmup

Stichwort: Einmal am Tag den Cache leeren und aufbauen.

[Spooky]

Redirect eingerichtet.

- - - Aktualisiert - - -

Danke für den Link!

Hat jemand zufällig ein Snippet bereit, wie ich folgende beiden Befehle alle 24 Stunden ausführen kann?

vendor/bin/contao-console cache:clear --no-warmup
vendor/bin/contao-console cache:warmup

Stichwort: Einmal am Tag den Cache leeren und aufbauen.

Warum würdest du das machen wollen?

[Troy]

Das ist sehr einfach erklärt: Aus technischen Gründen habe ich vor 1,5 Wochen meinen Frontend-Cache auf 5 Minuten eingestellt. Das in Kombination mit 1000 Seiten und über 1 Million Seitenaufrufen pro Monat hat dazu geführt, dass mein Cache innerhalb dieser kurzen Zeit von Null auf 30 GB "vollgelaufen" ist und ich eine Warnung von meinem Hoster bekommen habe ("Ihr Webspace ist fast voll. Bitte löschen Sie Daten, um die Stabilität Ihre Servers zu gewährleisten.")

Nur nebenbei: Aufgrund der großen Datenmenge im Cache konnte ich im Backend weder "Systemeinstellungen" aufrufen (Maximum execution time) noch wurde der Contao-Manager damit fertig (Fehlermeldung...irgendetwas mit "not empty directory"). Gott sei Dank, halfen die oben genannten Kommandos, um mich nach wenigen Minuten (!) von der Datenmenge zu befreien.

Wenn es eine bessere Lösung für mein Problem gibt, als per Cronjob den Cache zu leeren, dann nur her damit ;-)

PS: Auf meinem Server könnte ich auch einen "echten" Cronjob aufsetzen.

[Troy]

Wenn es bei den oben genannten Befehlen zu einem Fehler kommt, werden diese dann über die Standardfehlerausgabe (stderr) ausgegeben?

[Spooky]

Das ist sehr einfach erklärt: Aus technischen Gründen habe ich vor 1,5 Wochen meinen Frontend-Cache auf 5 Minuten eingestellt. Das in Kombination mit 1000 Seiten und über 1 Million Seitenaufrufen pro Monat hat dazu geführt, dass mein Cache innerhalb dieser kurzen Zeit von Null auf 30 GB "vollgelaufen" ist und ich eine Warnung von meinem Hoster bekommen habe ("Ihr Webspace ist fast voll. Bitte löschen Sie Daten, um die Stabilität Ihre Servers zu gewährleisten.")

Du redest hier vom Seitencache. Die Kommandos, die du gepostet hast, würden den gesamten Applikationscache löschen und neu aufbauen. Wenn du den Seitencache löschen willst, brauchst du nur ein

0 0 * * * rm -r /path/to/contao/var/cache/prod/http_cache

in deinem crontab eintragen, um den Seitencache täglich zu löschen.

Nur nebenbei: Aufgrund der großen Datenmenge im Cache konnte ich im Backend weder "Systemeinstellungen" aufrufen (Maximum execution time) noch wurde der Contao-Manager damit fertig (Fehlermeldung...irgendetwas mit "not empty directory"). Gott sei Dank, halfen die oben genannten Kommandos, um mich nach wenigen Minuten (!) von der Datenmenge zu befreien.

Wenn es eine bessere Lösung für mein Problem gibt, als per Cronjob den Cache zu leeren, dann nur her damit ;-)

Es wird an einer Lösung gearbeitet, die das Problem verringern kann: https://github.com/contao/contao/pull/1624

[Spooky]

Moderation: Posts in eigenen Thread verschoben.

@Troy: ich vermute dir geht es auch eher um Contao 4.9, nicht um 4.4?

[Troy]

Nein, die Seite läuft wirklich unter 4.4.

[Troy]

Nachdem ich mit den obigen beiden Befehlen via echtem Cronjob den ganzen Cache geleert habe, kann ich mich nicht mehr in das Backend einloggen:

domain.tld/contao/login führt zu

Internal Server Error
Was ist das Problem?
The directory "/var/www/vhosts/domain.tld/var/cache/prod/contao/cache" does not exist and could not be created.

Wenn ich im Contao-Manager "Prod.-Cache erneuern" klicke, erhalte ich:

Failed to remove file "/var/www/vhosts/domain.tld/var/cache/prod/annotations.php": unlink(/var/www/vhosts/domain.tld/var/cache/prod/annotations.php): Permission denied.

---

### Der Hintergrundprozess wurde unerwartet beendet ###

Anmerkung: Der Ordner /var/cache/prod/contao/cache existiert sehr wohl. Komisch.

Hat der Cronjob irgendwelche Berechtigungen geändert? Was ist da passiert?

[Spooky]

Hast du die Berechtigungen überprüft?

- - - Aktualisiert - - -

Nein, die Seite läuft wirklich unter 4.4.

Du solltest auf Contao 4.9 aktualisieren.

[Troy]

Ja, es liegt an den Berechtigungen!

Plesk führt Cronjobs standardmäßig als root aus. Beim Neuanlegen des Cache wurde der Ordner var/cache/prod dann dem Benutzer root zugeordnet...und leider habe ich keinen root-Zugriff -> Mail an den Hoster ist raus.

(Warum jetzt auf 4.9? Ich bleibe meistens bis kurz vor EOL auf der LTS. Habe Angst davor, was kaputtzumachen. Gebe zu, dass meine Strategie zur Angstbewältigung nicht hilft.)

[Spooky]

Ja, es liegt an den Berechtigungen!

Plesk führt Cronjobs standardmäßig als root aus. Beim Neuanlegen des Cache wurde der Ordner var/cache/prod dann dem Benutzer root zugeordnet...und leider habe ich keinen root-Zugriff -> Mail an den Hoster ist raus.

Was genau hattest du im crontab eingetragen? Das was ich gepostet habe würde auf keinen Fall irgendwas neu anlegen - und daher auch keine Berechtigungen ändern.

(Warum jetzt auf 4.9? Ich bleibe meistens bis kurz vor EOL auf der LTS. Habe Angst davor, was kaputtzumachen. Gebe zu, dass meine Strategie zur Angstbewältigung nicht hilft.)

Caching funktioniert in Contao 4.9 viel besser. Wenn Caching für dich wichtig ist, solltest du auf Contao 4.9 aktualisieren.

[Troy]

Diesen Befehl habe ich von Plesk (Benutzer: root) ausführen lassen:
/opt/plesk/php/7.2/bin/php /var/www/vhosts/domain.tld/vendor/bin/contao-console cache:clear --no-warmup && /opt/plesk/php/7.2/bin/php /var/www/vhosts/domain.tld/vendor/bin/contao-console cache:warmup

Das hat dazu geführt, dass der Ordner var/cache/prod statt myuser plötzlich root zugeordnet wurde.

Ja, dein Befehl ist besser. Dort wird kein Ordner angelegt und deshalb werden keine Berechtigungen geändert.

Danke für deine Hilfe!

PS: Werde dann demnächst auf 4.9 upgraden!

[Troy]

Anmerkung für Plesk-User: Entgegen vorheriger Aussagen kann man in Plesk sehr wohl Cronjobs auch als nicht-root anlegen.

Unter "Tools & Einstellungen > Geplante Aufgaben" werden Cronjobs unter dem Benutzer root angelegt.
Unter "Websites & Domains > Geplante Aufgaben" werden Cronjobs unter dem Benutzer myuser angelegt.

Mein Hoster empfiehlt: "Bitte vermeiden, Cronjobs unter root anzulegen."

Thema erledigt.