Typo3 Caching Grundlagen

Typoscript (TS) Cache-Optimierungen

Folgend einige Typo3script Cache-Optimierungen. Details zu den meisten Parametern finden sich unten im Text:

## Enable caching and various optimizations parameters
config.concatenateJs = 1
config.concatenateCss = 1
config.compressJs = 1
config.compressCss = 1
config.sendCacheHeaders = 1

# set page cache default timeout to 1 month (value in seconds)
config.cache_period = 2592000
config.cache_clearAtMidnight = 0

Die folgenden Inhalte wurden auf typo3blog.at entdeckt und grösstenteils übernommen: http://typo3blog.at/blog/artikel/typo3-caching-grundlagen/. Vielen Dank für diese ausführliche Zusammenstellung!

Anmerkung: Eine Konfigurationsanleitung hierzu findest du in diesem KB-Artikel: Typo3 6.0 Performance-Optimierungen :: Konfigurieren des Error Reportings und Deaktivieren diverser Logging-Einstellungen, Aktivieren von Kompressionseinstellungen

Der TYPO3 Cache spielt eine große Rolle bei der Performance einer TYPO3 Website. Ein kurzer Einblick in die Grundlagen und dessen Konfiguration vermittelt dem angehenden TYPO3 Integrator wichtige Kenntisse.

Installiert man TYPO3, ist der Cache (TYPO3 Frontend Cache) per Standard aktiviert. TYPO3 besitzt ein ausgefeiltes Caching-System, welches man mit der richtigen Konfiguration sehr performant machen kann.

Ändert man selbst (oder eine zusätzlich installierte Extension) nichts am Caching-Verhalten von TYPO3 werden die Seiten automatisch in die Caching-Tabelle geschrieben.  Hat man seine TYPO3 Website erstellt und navigiert per Browser einige Seiten an, sollte sich die Tabelle mit Cache-Einträgen füllen.

Für mich gilt, Inhalte die sich nicht ändern, sollten auch so lang als möglich im Cache bleiben. In den meisten Projekten kommt es vor, dass ich config.cache_period = <Wert in Sekunden> im TS-Setup stets einen hohen Wert von mehreren Wochen, ja sogar Monate zuweise. Auch versuche ich stets kleine News-Teaser, die auf jeder Seite angezeigt werden per AJAX nachzuladen - damit bleibt der Hauptcontent im Cache und nur ein kleiner Teil wird nachgeladen.

Es gibt allerdings durchaus Gründe, die dafür sprechen, die Cache-Lebenszeit auf zB. 24 Stunden zu stellen. Möchte man dann auch stets eine performante Website haben, kann man hierfür in den frühen Morgenstunden die Extension Crawler einsetzen, die auf alle Seiten zugreift und so das Befüllen des Caches in Gang setzt.

Das TypoScript Setting config.cache_clearAtMidnight = 1 veranlasst TYPO3 den Cache beim ersten Aufruf nach Mitternacht zu erneuern.

Ich hatte erst kürzlich für einen Kunden den Auftrag, dessen TYPO3-Website zu überprüfen, da sein Provider meint, die Datenbank hätte schon eine Größe von über 10GB erreicht, seine Quota läge aber nur bei 1GB. Ein kurzer Blick auf die Website brachte mich schon zum Lächeln.
Als ich mich dann in die Datenbank einloggt hatte wurde mein Verdacht bestätigt! Die Cache-Tabellen sind sehr groß geworden. Hat jemand auf der Website tatsächlich in die Sidebar einen Mini-Kalender eingebaut, welcher vom Caching nicht ausgenommen wurde und so klarerweise (größtenteils) der Google-Bot dafür schuld war, weil dieser auf jeder Seite, die Vor- & Zurück-Links des Mini Kalenders verfolgt hat.

Seitdem gebe ich besonders Acht auf das Caching-Verhalten sobald TypoScript Conditions oder/und FE-Benutzerlogins hinzu kommen. Für mich gilt seither, Browserweichen wenn möglich nicht in TypoScript Conditions auszulagern. Nutzt man z.B. eine solche Browserweiche mit TS Conditions und Conditions für FE-Benutzergruppen, möchte ich gar nicht erst beginnen zu rechnen, wieviele mögliche Caching-Einträge es in die Datenbank schaffen!

Möchte man das Caching global deaktivieren (z.B. während dem Developen der Website) wird dies im SETUP-Feld des Root-Templates (oder für den Bereich der Website, wo das Caching deaktiviert sein soll) über config.no_cache = 1 / page.config.no_cache = 1 erreicht.

Eine weitere Möglichkeit, den Cache zu deaktivieren gibt es, wenn man als Backend-Benutzer eingeloggt ist, sich im Frontend befindet & das Admin-Panel und die dafür nötigen Einstellungen aktiviert hat. Dann bietet einem das Admin Panel auch die Möglichkeit an, zu sehen, wieviele Chache-Einträge für die aktuelle Seite gespeichert sind.

Den Aufbau der /typo3conf/temp_CACHED_*-Dateien unterdrückt man, indem man die Install Tool Option $TYPO3_CONF_VARS['EXT']['extCache'] = '0' setzt. Diese Einstellung ist dann sinnvoll, wenn man manuell Änderungen an den ext_*-Dateien seiner Extension vornimmt.

Anmerkung: Ab Typo3 6.0 ist $TYPO3_CONF_VARS['EXT']['extCache'] = '0' wegen des überarbeiteten Caching-Systems unwirksam!

Lagert man sein TypoScript ins Filesystem aus, wie ich es sehr gerne mache, dann werden diese Files auch gecacht. Ausschalten kann man dies durch Setzen von admPanel.override.tsdebug.forceTemplateParsing = 1 im UserTSConfig. Sobald man sich im Backend eingeloggt hat, werden für Aufrufe des Frontends in dieser Browser-Session die Files immer neu eingelesen.

Bei normalen Seiteninhalten (tt_content) wird der Cache der betroffenen Seite automatisch geleert, nachdem man ein Element gespeichert hat. Newsdatensätze hingegen speichert man in der Regel außerhalb der sichtbaren Seiten in sog. sysFolders. Legt man an dieser Stelle einen neuen Newsartikel an oder ändert diesen, dann wird der Cache für Seiten auf denen das Newsplugin zum Einsatz kommt, nicht automatisch geleert. Daher kann man per PageTSConfig die Seiten-UIDs festlegen, für welche der Cache geleert wird:

Sobald nun neue Newsdatensätze eingestellt oder bearbeitet werden, wird auf diesen Seiten automatisch der Cache geleert.

Um einem normalen Redakteur die Rechte zu geben, den FE-Cache von Frontend-Seiten zu löschen, genügen folgende beiden Zeilen TypoScript für die jeweilige BE-Benutzergruppe:

Es erscheint dann im Backend oben rechts auch der gelbe Blitz mit einem Kontextmenü, über welches das Löschen vorgenommen werden kann.

sollten möglichst gemieden werden. Es wird dadurch zwar nicht das gesamte Caching deaktiviert, sondern nur der Inhalt des _INT Objektes. Hat man viele dieser _INT Objekte auf einer Seite und keine Möglichkeit, diese mittels Javascript oder AJAX zu entfernen, kann es sinnvoll sein, das Caching für diese Seite zu deaktivieren. In einigen Fällen habe ich bereits gesehen, dass so der Seitenaufruf schneller vonstatten geht.

Immer wieder entdecke ich Extensions im TER, welche das Caching auf diese Art und Weise abschalten. Dies schaltet jedoch den gesamten Cache der Seite ab und ist deshalb für viele ein Grund, die Extension nicht zu verwenden! Daher stets den kompletten Quellcode (speziell bei der Verwendung von Extensions aus dem TER) nach $GLOBALS['TSFE']->set_no_cache()  durchsuchen.

Als Lösung kann man entweder die betroffene Extension vom System nehmen, eine Alternative suchen, oder aber den PHP-Code so modifizieren, dass ein komplettes Deaktivieren des Caches nicht mehr stattfindet.

Realisiert man eine Sprachumschaltung muss man sogenannte linkVars verwenden. Grenzt man die möglichen Werte für die einzelnen Parameter nicht ein, kann ein Bösewicht - ruck zuck - die Cache-Tabelle(n) damit befüllen. Hat man beispielsweise 3 aktive Sprachen im Frontend, sieht die Konfiguration hierfür so aus:

config.linkVars = L(0-2)

Nimmt man darauf keine Acht, können einem die Cache-Tabellen enorm anwachsen! Dies gilt übrigens für alle in config.linkVars definierten Parameter. Ausführliche Dokumentation zu config.linkVars

Verwendet man in seinem Projekt den Get-Parameter &no_cache=1 nicht, kann man dessen Funktionalität über das Install Tool bzw. in der localconf.php direkt abschalten.

$TYPO3_CONF_VARS['FE']['disableNoCacheParameter'] = '1';

ist dafür verantwortlich. So wird verhindert, dass jemand unnötig Last am Server entwickeln kann.

Es kommt manchmal leider vor, dass das Caching aufgrund unterschiedlichster Gegebenheiten nicht wie geplant arbeitet. Mit etwas Detektivarbeit kann man dem auf den Grund gehen:

Cache Datenbanktabellen durchforsten

Zuerst würde ich den FE-Cache leeren und anschließend mehrere Seiten in einer anderen Browser-Session ansurfen. Wurde(n) die Seite(n) nach deinem Aufruf gecacht, muss nun ein Eintrag in der dafür vorgesehenen Tabelle sein. Bei älteren TYPO3-Versionen handelt es sich dabei um die Tabelle mit der Bezeichnung cache_pages, in neueren Versionen cachingframework_cache_pages bzw. cf_cache_pages.

Bleiben die Einträge aus, arbeitet das Caching an irgendeiner Stelle fehlerhaft. An dieser Stelle ist es ratsam zu überprüfen ob man nicht doch selbst dafür verantwortlich ist:

• Caching deaktiviert in den Seiteneigenschaften
• Caching deaktiviert per TypoScript
• Caching deaktiviert per Get-Parameter &no_cache=1

Gibt es keine Anzeichen dafür, dass man das Caching absichtlich deaktiviert hat, aktiviert man zunächst das Admin Panel im Frontend.

Check im Frontend mithilfe des Admin Panel

Aktivieren des Admin Panels sowie TypoScript für diese Testzwecke:

Anschließend leert man den kompletten Cache im Backend und wechselt in der selben Browser-Session zum Frontend, wo man dann am untersten Ende der Seite im Admin Panel den Bereich Cache aufklappt. Wird einem hier bei Cache Einträge ein Wert ungleich 0 ausgegeben, funktioniert das Caching.

Ist dem nicht so, wäre es möglich das die Cache-Tabellen kaputt sind. Über phpMyAdmin, t3adminer oder der Shell mit Zugriff auf den MySQL-Prompt, kann man nun versuchen die Tabellen mittels REPAIR zu reparieren.

Funktioniert es nach einem weiterem Test noch immer nicht, so kann es eigentlich nur noch daran liegen, dass irgendwo im Quellcode (Extensions, userfunctions) ->set_no_cache(); verwendet wird. Weitere Infos zu ->set_no_cache();

Suche nach no_cache per TS Object Browser

Ebenso kann man im TypoScript Object Browser nach der Zeichenkette no_cache suchen (Bereich Setup).

Mit diesen Möglichkeiten sollte man dem Caching-Problem auf die Schliche gekommen sein.

Zum Thema cHash gibt es seit kurzem einen Blogbeitrag AOE media. Zum Blogbeitrag "TYPO3 Caching and the cHash".