TYPO3 4.0Das Handbuch für TYPO3-Entwickler
und Administratoren

Welchen Sinn hat das Caching?

Die dynamische Erzeugung einer Webseite mittels TYPO3 ist ein rechenintensiver Prozess. Unter anderem werden die TypoScript-Eintragungen in ein PHPArray gerendert und anhand dieses Arrays dann ein Baum aus Objekten aufgebaut. Schließlich erzeugen diese Objekte gemeinsam die auszugebende HTML-Seite. Dieser aufwendige Prozess würde für jeden Aufruf derselben Seite immer wieder viel Arbeitsspeicher und Prozessorkapazität verbrauchen, der bzw. die besser für eine schnellere und häufigere Auslieferung von Webseiten zur Verfügung steht.

Daher sieht TYPO3 vor, die unveränderten, statischen Seiten nach ihrer Erzeugung als HTML-Code in der Datenbank zu speichern und diese bei einem erneuten Aufruf derselben Seite fertig auszuliefern, ohne den ganzen Rendering-Prozess neu anzustoßen. Zu vergleichbaren Optimierungszwecken werden auch verschiedene Konfigurationseinstellungen nach ihrem Rendering als Datei oder in der Datenbank zwischengespeichert.

Das Caching hat nicht nur Vorteile. Werden als statisch gecachte Inhalte im Rahmen der Entwicklung oder Inhaltspflege geändert, müssen die Caches aufgefrischt werden. Da das leider in vielen Fällen nicht automatisch passiert, müssen die Caches häufig gezielt geleert werden. Es passiert nicht nur unerfahrenen Benutzern, dass sie durch veraltete Ausgaben aus einem nicht aktualisierten Cache irritiert werden.

Was wird gecacht?

Neben der HTML-Ausgabe statischer Seiten werden verschiedene Konfigurationseinstellungen gecacht, außerdem Bilder-Abmessungen, Objektbäume teils in Tabellen, teils als Dateien. Auch verschiedene Extensions bringen Caching-Mechanismen mit. Bilder und andere Dateien, die auf den Server geladen werden, zählen dagegen nicht zum Cache, wohl aber die dazu erzeugten Thumbnails.

Welche Konfigurationen werden gecacht?

Von Bedeutung sind die Dateien ext_localconf.php und ext_tables.php der verschiedenen installierten Extensions inklusive der Basis-Extension »CMS«. Diese werden gemeinsam in Datein im Ordner typo3conf gecacht, die mit temp_CACHED_ beginnen. Das gilt allerdings nur im Standardfall, wenn $TYPO3_CONF_VARS["EXT"]["extCache"] = 1 gesetzt ist. Andernfalls werden die Dateien nicht gemeinsam gecacht, sondern einzeln eingebunden.

Normalerweise kann man diesen Cache mit dem Link »Clear temp_CACHED« im Modul-Frame des Backends leeren, wenn man mit Administratorrechten eingeloggt ist. Das ist während Extension-Entwicklungsarbeiten an diesen Dateien nötig.

Tipp: Es kann dem Extension-Entwickler beim Arbeiten an den Dateien ext_localconf.php und ext_tables.php passieren, dass der Modul-Frame infolge Programmierfehlern gar nicht mehr ausgegeben wird, so dass dieser »Lösch-Link« auch nicht mehr zur Verfügung steht. Dann kann man sich damit behelfen, diese temp_CACHED-Dateien im Ordner localconf/ direkt zu löschen.

Tipp Während der Entwicklung lohnt es sich also auch, $TYPO3_CONF_VARS["EXT"]["extCache"] = 0 zu stellen, um diese Probleme zu minimieren.

Wo werden Dateien gecacht?

Bilder und Dateien kann man zum mehrfachen Gebrauch ins Archiv unterhalb von fileadmin/ ablegen. Werden sie zum einmaligen Gebrauch direkt aus Content-Objekten hochgeladen, werden sie unterhalb von uploads/ abgelegt. In beiden Fällen handelt es sich NICHT um gecachte Dateien.

Werden diese Dateien vor der Ausgabe jedoch weiterverarbeitet z.B. zu Thumbnails, so werden diese Stufen der Weiterverarbeitung im Ordner typo3temp/ gecacht. Werden sie hier gelöscht, so sollten sie von der jeweiligen Extension automatisch neu erzeugt werden. Das Löschen des Frontend-Caches führt nicht zum Löschen dieser Dateien.

Wo werden die gecachten Seiten gespeichert?

Die Ausgabeseiten bzw. ihre Elemente werden insbesondere in den Tabellen cache_pages und cache_hash gespeichert. Es gibt einige weitere Tabellen, die mit cache_ beginnen, z.B. cache_imagesizes, die die Zuordnung von gecachten Bilddateien zu ihrem Original und den Ausmaßen der gecachten Seite beinhaltet.

Wie werden nicht gecachte Objekte aus gecachten Seiten angestoßen?

PHP_SCRIPT_INT-Objekte sollten zugunsten von USER_INT-Objekten nicht mehr eingesetzt werden. Für beide gilt in Bezug auf das Caching Analoges. Die statischen Bereiche der HTML-Ausgabe werden wie gewohnt gecacht. An der Position, wo das dynamische Plugin zur Entfaltung kommt, wird jedoch lediglich ein Marker gespeichert. Der Rendering-Prozess findet mindestens in Teilen statt, soweit er nötig ist, um die aktuelle Umgebung für das dynamische Plugin zu erzeugen. Dieses findet damit die gleiche Variablen-Umgebung, als würde die Seite gar nicht gecacht. Das Ergebnis des dynamischen Plugins wird dann an Stelle des zugehörigen Markers in die übrige statische HTML-Datei eingesetzt.

Wie sind die Cache-Control-Header gesetzt, die das Caching der Seiten in Browsern und Proxies beeinflussen?

Standardmäßig werden keine Cache Control Header gesendet, die das Caching von Seiten in Proxies und Browsern initiieren, aber auch keine, die es explizit untersagen würden.

Mittels TypoScript-Setup config.additionalHeaders = xyz lassen sich Header  frei definieren. Seit Version 3.8.0 gibt es die Einstellung config.sendCacheHeaders = 1 , wodurch automatisch Cache-Control-Header gesetzt werden.

Ein solches Caching kann durchaus Last vom Server nehmen. Man muss allerdings sicherstellen, dass die entsprechende Seite wirklich statisch ausgeliefert werden kann und keinerlei dynamische Funktionen enthält. Die Einstellung config.sendCacheHeaders = 1 übernimmt auch diese Kontrolle. Durch ein solches Caching wird die Zugriffsstatistik in den Logfiles allerdings verfälscht.

Für Seiten, die in einem geschützen Userbereich liegen, gilt es besondere Einstellungen zu beachten. Siehe hierzu:

typo3.org/development/articles/using-cache-control-headers-in-typo3/

Tipp:

Ein Proxy muss nicht unbedingt auf Seiten des Empfängers stehen. Man kann einen solchen Rechner auch zum Zwecke der beschleunigten Auslieferung als Cache direkt vor den Webserver setzen.

Wie verhalten sich Caching und Indizierung zueinander?

Grundsätzlich werden nur Seitenteile zur Suche indiziert, die auch gecacht werden. Das bedeutet, dass man sowohl den Parameter no_cache=1 als auch USER_INT-Objekte vermeiden sollte, um eine weitreichende Indizierung der Seite bzw. der Plugin-Ausgabe zu erreichen. Während no_cache=1 dazu führt, dass die gesamte Seite nicht indiziert wird, führt das USER_INT-Objekt dazu, dass zumindest die gesamte Plugin-Ausgabe nicht indiziert wird.

Wann benutze ich $GLOBALS["TSFE"]->set_no_cache(), wann USER und wann USER_INT?

Der Parameter no_cache=1 kann auf zwei Arten gesetzt werden. Entweder wird er als Parameter mit dem URL / dem Formular übergeben, oder er wird innerhalb eines Plugins explizit per Funktion gesetzt ($TSFE->no_cache();).

Er führt dazu, dass die gesamte Seite weder gecacht noch indiziert wird. Da die gesamte Seite auch jeweils neu gerendert werden muss, belastet diese Technik der Dynamisierung auch den Server am meisten. Dieser Parameter hat daher im laufenden Betrieb eigentlich nur Nachteile. Er wird aber gern im Rahmen der Entwicklung der USER-Plugins gesetzt, um diese statischen Plugins temporär dynamisch zu testen.

USER_INT-Objekte sind dann angebracht, wenn die Ausgabe wirklich dynamisch variiert, d.h. selbst dann noch variieren soll, wenn genau gleichartige Parameter zur Abfrage übergeben werden. Dieser Typ ist beispielsweise bei Ausgaben angebracht, die sich mit der Zeit ändern, wie die Ausgabe aktueller Börsenkurse. Auch Formulareingaben in eine Datenbank müssen dynamisch verarbeitet werden. Ein gecachtes USER-Objekt wäre hier sinnlos.

Soll dagegen bei einem Plugin die Übergabe gleicher Parameterwerte (in der Regel aus einem Link) auch zur Ausgabe des gleichen Anfrageergebnisses führen, wie in Linklisten oder News-Archiven, ist das USER-Objekt der Objekttyp der Wahl. Hierbei wird die &cHash-Technik eingesetzt, um unterschiedliche Varianten derselben Seite anhand der Plugin-Parameter zu unterscheiden.

Was hat es mit &cHash auf sich, und wie wendet man es an?

Beim Einsatz eines Plugins kann dieselbe Seite (mit den gleichen Parametern id und type) dennoch verschiedene Ausgabevarianten haben, in Abhängigkeit davon, welche Parameter für das Plugin übergeben werden. Ergeben sich für gleichartige Wertübergaben der Plugin-Parameter aber gleichartige Ausgaben, wie z.B. für Linklisten oder News-Archive, so empfiehlt es sich, diese unterschiedlichen Varianten einzeln zu cachen.

Um das zu erreichen, setzt man ein Plugin vom Typ USER ein. Wenn das Caching schon erlaubt ist, müssen die unterschiedlichen Varianten der Seite jedoch sauber voneinander getrennt werden, sonst erhielte man auch bei unterschiedlichen Anfragen doch immer die gleiche Ausgabe aus dem Cache.

Erkennt der Caching-Mechanismus also eine neue Kombination von type, id und Parameterübergabe (und ist für diese Seite das Caching erlaubt), so speichert der Caching-Mechanismus die Ausgabe der Seite als eine neue statische Variante in der Datenbank. Er liefert sie beim nächsten gleichartigen Aufruf aus.

Gäbe es da keinen zusätzlichen Sicherheitsmechanismus, ständen damit für DoS-Attacken (Denial-of-Service-Attacken) allerdings Tür und Tor offen. Bei wiederholten Aufrufen einer Seite mit beliebigen Zufallsparametern würde die Datenbank mit entsprechend vielen Seitenausgben aufgefüllt, auch wenn diese lediglich Fehlermeldungen des Plugins enthielten. Um solche DoS-Attaken zu verhindern, verwertet das Caching-System nur Parameter, die vom Server selbst »signiert« sind. Die URLs mit den Parametern enthalten dazu als Unterschrift einen zusätzlichen Parameter, den &cHash. Dieser wird aus einer Kombination der Parameter und einem serverinternen »Geheimwert« berechnet. Nur mit Hilfe dieses »Geheimwertes« lassen sich dann auch die signierten Parameter überprüfen.

Der serverinterne »Geheimwert« wird mit folgender Einstellung auf einen individuellen Wert gesetzt:

$TYPO3_CONF_VARS[SYS][encryptionKey]

URL werden automatisch von der Funktion typolink() mit dieser Signatur versehen, wenn man den Konfigurationsparameter ?useCacheHash? setzt. Durch die Benutzung der Linkfunktionen der Klasse pi_base greift man indirekt ebenfalls auf die Funktion typolink() zu. Bei den meisten dieser Funktionen wird die Erzeugung des &cHash Paramters dadurch ausgelöst, dass man den Paramter $cache = 1 übergibt.

Beispiel:

$label = 'Details ...';

$params = array('uid' => $uid, 'action' => 'showDetails');

$anker = $this->pi_linkTP_keepPIvars($label, $params, 1, 1);

TIP: Eine Dokumentation der Klasse pi_base wird mit dem Extension Development Evaluator installiert.

Es bleibt ein Problem, das so genannte Problem des »leeren &cHash«. Wird eine Seite beim ersten Aufruf mutwillig oder irrtümlich mit sinnvollen Parametern, jedoch ohne &cHash aufgerufen, erzeugt sie die spezielle Ausgabe für diese Parameterwerte. Sie wird jedoch für eine Normalausgabe ohne Zusatzparamter gehalten, denn Zusatzparameter werden nur in Verbindung mit einem &cHash erkannt. Deshalb wird die spezielle Ausgabe fälschlicherweise als neue Normalausgabe im Cache abgelegt. Beim nächsten Aufruf ohne Plugin-Parameter wird statt der erwarteten normalen Seite die abgespeicherte spezielle Ausgabe geliefert.
Das Problem tritt typischerweise nach dem Löschen des Caches auf, wenn paramterbehaftete Links aufgerufen werden, denen aus irgendwelchen Gründen der &cHash fehlt. Besonders im Zusammenspiel mit der Extension »realURL« führte das u.a. auf www.typo3.org zeitweilig zu großer Verwirrung.
Um hier Abhilfe zu schaffen, sollte man in Klassen-Definitionen, die als USER-Objekte eingebunden werden, immer folgende Zeile eintragen:

var $pi_checkCHash = TRUE;

Der zugehörige Sicherheitsmechanismus greift ab TYPO3 Version 3.8.0. Auch in älteren Versionen stört der Eintrag nicht. Hier kann aber das Problem des leeren &cHash noch weiterhin auftreten.

Was bewirken welche Clear-Cache-Links und Buttons?

Adminlinks:

1. Cache in typo3conf löschen
   bewirkt das Löschen der gesammelten Konfigurationen der Extension-Dateien ext_localconf.php und ext_tables.php.
2. Alle Caches löschen
   bewirkt das Löschen der gespeicherten HTML-Ausgaben aus der Datenbank und den Template-Caches.

Je nach Konfiguration haben Editoren unten auf der Seite folgende 3 Möglichkeiten, den Cache zu leeren:

1. Diese Seite
2. Seiten-Cache löschen
   (Alle Caches der HTML-Seiten werden gelöscht.)
3. FE-Cache löschen
   (Auch die Caches für TypoScript-Templates werden gelöscht.)

Welche Oberflächen-Einstellungen gibt es zur Modifizierung des Caching einer Seite?

1. AdminPanel:

Hier lässt sich der Frontend-Cache löschen, auch gemeinsam mit Sub-Leveln. Es lässt sich die Option »no caching« wählen, woraufhin überhaupt kein Frontend-Caching mehr durchgeführt wird.

2. Backend-Seitentitel:

Hier können Sie eine Dauer für das Frontend-Caching dieser Seite einstellen. Das Caching lässt sich hier auch seitenweise ganz unterbinden (no caching).

Welche Konfigurationseinstellungen beeinflussen das Caching-Verhalten?

Mit den folgenden Einstellungen können Sie das Caching im TypoScript-Setup beeinflussen:

• Frontend-Cache global ausschalten: config.no_cache = true
• Allgemeine Einstellung für den Cache-Verfall in Sekunden: config.cache_period = 86400
• Gesamten Cache um Mitternacht löschen: config.cache_clearAtMidnight = true
• Analoge Einstellungen auf Ebene eines bestimmten Seitenobjekts z.B. page oder menu überschreiben die globalen Einstellungen: page.config.no_cache = ... menu.config.no_cache = ...

Wie interagieren Extensions mit den Caching-Mechanismen?

Was das Caching der Konfigurationsdateien angeht, so ist dieses für die Extensions einheitlich gelöst. Gleiches gilt für das Caching des TypoScripts.

Wie weit die Frontend-Ausgabe gecacht wird oder nicht, hängt davon ab, ob in der Extension in sinnvoller Weise von USER- und USER_INT-Objekten Gebrauch gemacht wurde und ob die Links korrekt erzeugt wurden.

Welche Konfigurationen kann man als Entwickler während des Bearbeitens treffen, um nicht ständig den Cache leeren zu müssen?

1. Frontend-Cache-Setup: config.no_cache = true
2. Konfiguration: $TYPO3_CONF_VARS["EXT"]["extCache"] = 0

Vergessen Sie nicht, anschließend die Werte zurückzusetzen, damit ein sinnvolles Caching greifen kann!