Caching in TYPO3 – Teil 3

In den vorigen Kapiteln unserer Caching-Blog-Reihe haben wir uns mit den verschiedenen Caching Mechanismen und Cache Varianten für das Rendering einer Frontend Seite in TYPO3 beschäftigt. Aber das war nur der Anfang. Wie bereits erwähnt macht TYPO3 noch wesentlich mehr mit Caches als nur das der Frontend Ausgabe. Wir schauen uns genau an, welche Arten von Caches es gibt und wann sie eingesetzt werden.

1. Das Caching Framework

Während der TYPO3 v4 Entwicklung wurde bis 2011 der TYPO3 Core auf das sogenannte Caching Framework migriert. Das  Caching Framework („cf“) besteht aus verschiedenen „Caches“ — und jeder hat einen speziellen Zweck. Jeder Cache besteht aus einem Storage Backend (der Ort, wo die Cache-Einträge abgelegt werden), und einem Frontend (der weiß welche Daten-Typen in diesen Cache abgelegt werden können).

Eines der Stärken des Caching Frameworks ist es, verschiedene Cache Backends pro Installation zu konfigurieren. Ein Beispiel: Das Database Backend, welches alle Cache Einträge in einer Datenbank Tabelle speichert, ist praktisch wenn der Datenbank-Server keine oder kaum Netzwerk-Latenz hat. Wenn die Datenbank aber über ein langsames Netzwerk erreichbar ist oder die Server-HDDs langsam sind, ist es sinnvoller, ein anderes Caching-Backend zu nutzen, welches performanter in der Server-Umgebung funktioniert. Es gibt keine klare Antwort wie man die Caches eingerichtet werden sollen, aber es ist wichtig zu verstehen, welche Vor- und Nachteile jedes Cache Backend hat, um eine qualifizierte Entscheidung zu treffen.

2. Zurück zu den (Caching) Basics — Äpfel mit Birnen vergleichen

Um die Grundsätze des Caching Frameworks und eines einzelnen Caches zu verstehen, nehmen wir ein Beispiel von Äpfeln, die in einen Korb gelegt werden sollen.

• Cache Identifier: Ein einzelner Apfel, den Du in der Hand halten kannst, existiert nur ein einziges Mal - also könnten wir dem Apfel auch einen Namen geben wie z.B. Henry geben.
• Cache Tags: Aber die vielen Arten von Äpfeln... rote Äpfel, verfaulte Äpfel, oder saftige Äpfel. Wir könnten auf jeden Apfel verschiedene Aufkleber packen um die Eigenschaften eines jeden Apfels zu beschreiben.
• Lifetime / Gültigkeit: Und wie es ist in Deutschland so üblich ist, kann man auch jeden Apfel mit einem Ablaufdatum versehen. Sobald das Ablaufdatum erreicht ist, sind diese Äpfel einfach nicht mehr relevant für uns (sagen wir, man sollte sie nicht mehr essen).

Der Korb, in dem die Äpfel sind, ist gleichzusetzen mit einem einzelnen Cache. Wenn wir jeden Apfel hineinlegen, geben wir jedem Apfel einen Namen und auch passende Aufkleber.

Nun da wir einen vollen Korb an Äpfeln haben, können wir schnell diesen Korb durchsuchen und die passenden Äpfel finden. Und das sind auch die Fragen, die wir an einen Cache stellen: 

1. „Gebe mir den Apfel namens Henry.“
2. „Wirf den Apfel mit Namen Henry weg.“
3. „Werfe alle Äpfel aus dem Korb in den Mülleimer.“
4. „Werfe alle saftigen Äpfel weg .“
5. „Ausmisten — entferne alle Äpfel die abgelaufen sind aus dem Korb.“

Das, gepaart mit dem Hinzufügen von neuen Äpfeln, ist alles, was ein Cache braucht.

Nun, das ist jetzt ein Cache, aber wenn Du einen Korb mit Äpfel hast, und einen zweiten Korb für Birnen (wir mischen natürlich nie Äpfel mit Birnen) dann sind dies zwei unterschiedliche Körbe. Beide gehören der Cache Group „Früchte“ an, aber es könnte genauso eine weitere Gruppe „Gemüse“ oder was ganz anderes wie „Müsli“ geben. Das Müsli könnte man ja auch in eine Schüssel, oder eine Schachtel, und nicht in einen Korb packen — und das ist der Moment, an dem wir genau darauf achten, welches Cache Backend am Geeignetesten für Deine TYPO3 Installation. Die Caches in Gruppen zu sortieren, erlaubt es um mehrere Körbe / Schüsseln auf einmal zu leeren.

3. Cache Backends

TYPO3 Core liefert alle Cache Konfigurationen standardmäßig mit einem Datei-basierten Cache Backend oder dem Datenbank Cache Backend aus — weil dies das ist, was alle TYPO3 Installationen auf jeden Fall zur Verfügung haben. Aber der geeigneteste „Korb“, oder Cache Backend, hängt von der Server-Umgebung ab und wie diese auch aufgesetzt wurde. TYPO3 Core liefert von Haus aus folgende Möglichkeiten für Cache Backends mit:

TYPO3 Database & PDO-basierte Database Cache Backends

Dieser Ansatz legt alle Cache Identifier und die Inahlte in die relationelle Datenbank ab, die TYPO3 auch für Inhalt verwendet. Das TYPO3 Database Cache Backend erstellt automatisch das Schema für die Datenbank-Tabellen, die dafür benötigt werden (über den Datenbank Schema Vergleich werden diese dann auch erstellt), und stellt jeder Datenbank Tabellen ein „cache_“ voran (bzw. „cf_cache_“ bis TYPO3 v9). Das PDO-basierte Database Cache Backend kann verwendet werden, um den Cache in eine andere Datenbank zu speichern.

Vorteile:

• Eine gute Wahl für Caching in einer normalen Hosting Umgebung, bei der es keine speziellen Anforderung gibt.

Dies ist auch meine erste Wahl um Cache Daten zu debuggen wenn ich am TYPO3 Core arbeite und an Caching Themen arbeite.

Nachteile:

• Weil aller Content und andere Informationen auch in derselben Datenbank liegen, dauern Datenbank Backups länger und werden wesentlich größer. 
• In einem multi-node System mit einem RDBMS Cluster (z.B. Galera Cluster), ein Cache in der Datenbank ist zwar robust, aber erhöht auch die Latenz im Netzwerk.

Wenn wir Performance-Probleme in einer Website mit hoher Last haben ist der allererste Schritt die Caches aus der Datenbank zu packen, um der Datenbank Last abzunehmen.

Simple File Backend & File Backend mit Tagging

Ein einfaches („simple“) File Backend („Dateibasiertes Caching“) funktioniert wie folgt: Der Dateiname dient als „Cache Identifier“, und die Inhalte der Datei ist die zwischengespeicherte Information. Wenn Cache Tags benötigt werden, muss hier natürlich eine komplexere Logik verwendet werden, in dem alle Cache Tags in einer Control-Datei abgelegt werden. Dies macht alles natürlich etwas langsamer, aber wenn der Server mit einer flotten SSD Festplatte ausgestattet ist, ist das File Backend meist eine sehr gute Alternative um schnell die Performance zu steigern—aber auch um zu prüfen ob die Caches tatsächlich auch geschrieben werden.

Diese Cache Dateien werden üblicherweise im Ordner var/cache/ innerhalb der TYPO3 Installation abgelegt (bzw. unter  typo3temp/var/cache im Non-Composer-Mode).

Null-Cache Backend & PHP-Memory Cache Backend

Diese zwei speziellen Cache Backends sind nicht unbedingt etwas was Site Administratoren oder Extension Autoren direkt nutzen sollten, aber ich möchte sie trotzdem kurz erwähnen. Für das „NullCacheBackend“ und „TransientMemoryBackend“ a.k.a. „Runtime Cache“, nehmen wir nochmal das Beispiel der Äpfel her. Beim TransientMemoryBackend wird der Korb mit Äpfeln einfach am Ende des Tages einfach geelert, und wir starten am nächsten Tag mit einem leeren Cache wieder. Das Null Cache Backend hat als Korb einfach ein Loch im Boden, und somit kann sich der Korb nichts merken und wir finden auch nie was darin. 

Das TransientMemory Backend ist im TYPO3 Core stark in Verwendung, um während einem PHP Request Informationen zwischen zu parken, um wiederkehrende Aufgaben nicht in lokalen Variablen zwischen zu parken, z.B. das Berechnen von Backend Benutzer Permissions.

Im Gegensatz ist das Null Cache Backend perfekt um zu prüfen, in wie weit ein Cache tatsächlich einen Performance Sprung liefert, und erlaubt es Dir, TYPO3 komplett ohne Caching auszuführen—nur mit ein paar Zeilen Konfiguration.

Memory Caches—APC/APCu, WINcache, Redis, und Memcached

In der Computerverarbeitung ist der schnellste Weg um Puffer / Speicher „greifbar“ zu haben das RAM — der Zwischenspeicher – im Vergleich zur Festplatte / SSD oder dem Netzwerk. Auf Betriebssystem sind Dateisysteme und klassische relationale Datenbanken sind letztendlich optimierte, persistierte Caches, die Daten auf die Festplatte speichern, und um eine maximale Performance beim Lesen und Schreiben zu erhalten.

Die meisten RAM-basierten Caches benötigen PHP Erweiterungen oder Adapter die in PHP kompiliert werden. Heutzutage ist es aber sehr gängig diese PHP Erweiterungen über die üblichen Paket-Managern der Linux Distributionen nachzuinstallieren.

APC/APCu und WINcache—Memory-basierter Speicher für mehrere Web Requests

PHP’s interne Arbeiten um Arbeitspeicher zwischen mehreren PHP Requests zu parken—APC (bzw. APCu für „userland“ Cached Content)—wurden stetig erweitert und sind auf den meisten PHP7+ Servern verfügbar. Dies ist eine sehr gute, unkomplizierte Lösung, weil alles von PHP selbst gemanaged wird. Aber es hat auch gravierende Nachteile: Ein APC besitzt üblicherweise nur wenige Megabyte an Speicher und kann maximal auf ein paar Gigabyte ausgeweitet werden. Weil APC nur zwischen Web Requests geteilt werden kann, aber auf der Kommandozeile ein anderes PHP Binary zum Einsatz kommt, ist es technisch nicht ohne Weiteres möglich, APC-Caches der Web Requests über PHP-CLI zu leeren. Es gibt Workarounds, aber Komplexität dafür rechtfertigt es meiner Meinung nach, nach Alternativen zu schauen.

WINcache ist eine Windows-basierte Möglichkeit, um ein zusätzliches PHP Modul zu kompilieren, welches ähnliche Vorteile zu APCu liefert.

memcached und Redis—Key-Value Datenbanken

Einige „Key-Value Datenbanken“ haben sich die letzten Jahre am Markt etabliert. Sie alle speichern abgelegte Daten zuerst im Arbeitsspeicher / RAM um schnellen Lese- und Schreibzugriff zu ermöglichen. Diese laufen als separate Dienste auf dem Server, und anders als z.B. APC auch auf separaten Servern laufen, ähnlich wie eine MySQL Datenbank zwar auf demselben Server oder auch auf einem separaten Server angesteuert werden kann. Zwei der gängigsten Systeme sind „memcached“ und „Redis“. Deren optimiertes Datenbank-System ist die perfekte Lösung für memory-basiertes Caching. Die Menge an Daten die im RAM gehalten werden soll, kann konfiguriert werden und mehrere „Körbe“ / Caches können als separate, logisch getrennte Datenbanken im Service konfiguriert werden. Das einzige Limit hier ist der RAM, welcher dem Dienst zur Verfügung gestellt wird.

Mit Memory Caches wird deine Website immer schneller

Für jede mittelgroße oder große TYPO3 Installation empfehlen wir eines der beiden Key-Value Services (wir bevorzugen Redis bei b13), da unsere Websites damit ca. 30% schneller geladen haben, als wir von Datenbank-basiertem Cache Backends auf Redis gewechselt haben.

Jedes Cache Backend hat verschiedene Optionen, die angewandt werden können — ein File-basiertes Cache Backend kann konfiguriert werden um den Pfad zum Cache-Ordner zu konfigurieren, und ein Redis Cache Backend benötigt die Zugangsdaten zum Redis-Server um vollständig zu funktionieren.

TYPO3 selbst kann komplett erweitert werden um eigene Cache Backends zu entwickeln, es benötigt lediglich eine PHP Klasse die das Cache Backend Interface implementiert.

Eine kleine Randnotiz zu TYPO3 und PSRs: Die PHP Standards Recommendation Group (PHP-FIG) hat zwei Standards Recommendations für PHP Frameworks veröffentlicht: PSR-6 (Cache) und PSR-16 (Simple Cache). Das Caching Framework von TYPO3 und seine Features gab es bereits etliche Jahre vor diesen Standards und obwohl wir Standardisierungen gut finden, sind wir bis heute zögerlich, ein PSR zu übernehmen, da sie entweder zu viel spezifizieren (PSR-6 basiert auf einer per-Objekt-Basis für Cache Einträge) oder zu wenig (PSR-16 besitzt keine Tagging Funktionalität).

4. Welche Caches gibt es standardmäßig in TYPO3?

TYPO3 hat einige Caches standardmäßig eingebaut, und verwendet diese für verschiedene Zwecke. Wir schauen diese nun genauer an. Manche Caches wurden in älteren TYPO3 Versionen umbenannt oder zusammengefasst. Der Einfachkeit halber benutze ich die Namen der Caches wie sie in TYPO3 v10 verwendet werden.

Frontend-bezogene Caches

Du kennst bestimmt den „Clear Frontend Caches“ Button in TYPO3. Dieser leert alle folgenden Caches:

pages (Standard: Database)

Wir haben bereits auf die Cache Informationen von Seiteninhalten und Cache Varianten geschaut. Der „pages“ Cache beinhaltet alle diese Informationen, um die Inhalte einer Variante anzuzeigen.

pagesection (Standard: Database)

Der „pagesection“ Cache beinhaltet die TypoScript Konfiguration der sys_template Datensätze und TypoScript Dateien, die benötigt werden um eine Seitenvariante zu generieren. Quasi eine zusammengefasste Form aller TypoScript / Rendering Instructions für eine einzelne Seite ohne die TypoScript Conditions auszuwerten.

rootline (Standard: Database)

Der „Pagetree“ von TYPO3 generiert durch die „pid“ (Parent Page) und die „uid“ (die ID einer Seite) — ein flacher tabellen-basierter Ansatz — eine hierarchische Baumstruktur. Der Rootline Cache (hauptsächlich über die „RootlineUtility“ API verwendet) speichert Informationen über alle Eltern- und Großeltern-Seiten einer Seite. Diese Information wird unter anderem verwendet, um zu prüfen ob eine Seite im Frontend aufgerufen werden darf, oder eine Seite mit einer Site Konfiguratoin sauber verknüpft ist—oder sogar ob der aktuelle Webseiten-Besucher die Berechtigung hat, eine Seite zu sehen. Der Rootline Cache beinhaltet außerdem Rootline Varianten für MountPoints.

Ein netter Nebeneffekt: Wenn ein Redakteur durch das TYPO3 Backend klickt, wird dieser Cache auch befüllt und verwendet, und wenn anschließend ein Website Besucher eine Seite aufruft, die ein Redakteur im Backend angeklickt hat, ist der Cache für die Rootline bereits voll.

hash / cache_hash (Standard: Database)

Früher auch „cache_hash“ genannt. Ich würde sagen, dass „Sammelsurium“ das beste Wort ist um zu beschreiben, was TYPO3  in diesen Cache ablegt–also alles was nicht in eine der anderen Kategorien passt. In einer typischen TYPO3 Installation findest Du folgende Dinge:

• Das gecachte HTML eines Menüs für das TYPO3 Frontend, welches mit HMENU oder dem MenuDataProcessor Derivat gebaut wurde. (Schau Dir auch gerne mal unsere „menus“ Extension an, um zu schauen, warum wir glauben, dass HMENU konzeptionell nicht wirklich passend ist mit dem „hash“ Cache).
• TypoScript: Speichert pures TypoScript als Text für eine Seite ab mit allen Includes und externen Dateireferenzen.
• PageTSconfig: Die „page-relevanten TSconfig properties“ Information ist auch in einer nicht-evaluierten Form abgelegt.
• UserTSconfig: Ähnlich zu PageTSconfig, aber bezogen auf Backend Benutzer.
• Einzelne Content Teile („.cache“ stdWrap properties).
• Marker-basierte Templates (erinnerst Du dich an ### in TYPO3?).

System-bezogene Caches

Diese Caches werden in die „system“ Cache Gruppe abgelegt, weil sie nur geleert werden müssen, wenn die Systemkonfiguration oder Code geändert wurde. Das Leeren aller Caches der system Gruppe („Clear all caches“ leert auch alle Caches der system Gruppe) sollte auf Produktiv-Umgebungen nur gemacht werden, wenn ein Deployment durchgeführt wurde oder eine Extension installiert wurde.

Die meisten dieser Caches sind so konfiguriert dass sie auf das Dateisystem gelegt werden (File Based Cache). Das ist bereits optimal für die meisten Use Cases, außer wenn das TYPO3 Projekt auf einem NFS (Network File Share) System abgelegt wird, und der Zugriff auf das Dateisystem das System drastisch verlangsamen könnte.

assets (Simple File Backend)

Jegliches Icon im TYPO3 Backend, oder welches über die Icon API verwendet wird, wird im „assets“ Cache abgelegt. Zusätzlich liegt auch TYPO3’s RequireJS Konfiguration für das TYPO3 Backend in diesem Cache.

l10n (Simple File Backend)

TYPO3’s Unterstützung für Mehrsprachigkeit beziehen sich nicht nur auf den Inhalt, sondern auch auf alle Labels—sowohl für die Website (z.B. Validierungsfehler Nachrichten in einem Formular) als auch das gesamte TYPO3 Backend Interface. Alle Labels sind in verschiedenen XLIFF-basierten Dateien abgelegt — welche immer wieder geparsed werden müssen (XLIFF ist eben auch nur eine XML Definition). Diese Arbeit kann man getrost auch zwischen speichern, deshalb landen die Labels auch in einem Cache.

fluid_template (ein eigener FluidTemplateCache)

Die Templating Engine von TYPO3 – Fluid speichert die Templates als puren PHP Code im „fluid_template“ Cache, damit beim nächsten Aufruf der Seite das Templating kaum mehr Mühen und Arbeit hat.

extbase (SimpleFileBackend)

Extbase — TYPO3's MVC Framework für Plugins — arbeitet ausschließlich mit PHP Objekten und analysiert PHP Klassen für die Framework-spezifischen Features wie PHPDoc Annotations oder Dependency Injection, oder für die ORM Funktionen. Weil PHP Klassen im Produktiv-System sich nicht ändern, außer beim Deployment, sind diese Informationen auch gecacht.

core (SimpleFileBackend)

Während TYPO3 „bootet“ und alle Konfiguration liest, erstellt TYPO3 eine Liste aller Extensions, die geladen sind und wo diese Core Funktionalität verändern — entweder durch „ext_localconf.php“ Dateien, eigene TCA Konfiguration, PSR-15 Middlewares or weitere Backend Routen. Diese Informationen werden alle im Core Cache abgelegt. Beachte dabei, dass dieser Cache nicht „konfiguriert“ werden kann um in der Datenbank zu liegen, da das ein „Henne-Ei-Problem“ ist Keiner kann einen Apfel in einen Korb legen, wenn er nicht weiß, wo der „Korb“ ist um den Apfel hineinzulegen. Deshalb ist der Core Cache immer ein File Backend.

Seit TYPO3 v10 haben wir auch einen „di“ (Dependency Injection) Cache, der nur über das Install Tool in der Maintenance Area geleert werden kann. Dieser beinhaltet Informationen über registrierte Services und PHP Klassen. Wie bei den meisten anderen System-Caches ändert sich dies nur bei Deployments oder wenn eine Extension installiert oder deinstalliert wird, und das Aufbauen dieses Caches kann unter Umständen länger dauern, deshalb ist dieser hauptsächlich für PHP Entwickler relevant. Dieser Cache kann auch nicht auf ein anderes Cache Backend umkonfiguriert werden.

Weitere verfügbare Caches

imagesizes

Wenn Bilder auf der Website verwendet werden, wird die Bildergröße über eine API oder über das Dateisystem abgefragt. Der File Abstraction Layer von TYPO3 speichert sich diese Informationen bereits — auch für Processed Images, aber wenn Bilder über den GIFBUILDER oder ähnliche Funktionen generiert werden, wird diese Information in diesem Cache abgelegt, um unnötige Dateisystem-Abfragen zu vermeiden.

Dieser Cache liegt in der „lowlevel“ Cache Gruppe, die eigentlich nie geleert werden muss, weil die Größe eines dynamisch generierten Bildes sich eigentlich nie ändert.

runtime

Dieser Cache existiert nur für die Dauer eines einzelnen PHP Requests. Sobald die Response an den Browser geschickt wurde, wird der PHP Prozess in der Regel beendet und der Memory Cache ist wieder frei. Häufig wird dazu auch dies auch als „first-level cache“ bezeichnet, wenn Informationen im RAM abgelegt werden um nicht häufig auf das eigentliche Cache Backend (z.B. die Datenbank) zuzugreifen 

Und abschließend liefern folgende System Extensions noch weitere Caches mit, die nur aktiviert werden, wenn die Extension installiert ist:

• Admin Panel — adminpanel_requestcache
• Workspaces — workspaces_cache

5. Wie werden die Caches konfiguriert?

Jetzt weißt Du Bescheid – Zeit zum experimentieren:

Site Administrator ist die Hauptsache um bestehende Cache Konfigurationen auf andere Caches Backends zu setzen. Das geschieht häufig dann direkt in der System-Konfiguration in typo3conf/LocalConfiguration.php oder typo3conf/AdditionalConfiguration.php.

Um den Page Cache in das Dateisystem zu legen, machst Du folgendes:

1

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']['backend'] = \TYPO3\CMS\Core\Cache\Backend\FileBackend::class;

Um alle Frontend-relevanten Caches in Redis zu legen, machen wir das in der AdditionalConfiguration wie folgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$redisHost = '127.0.0.1';
$redisPort = 6379;
$cachesForRedis = [
    'pages' => 86400*30,
    'pagesection' => 86400*30,
    'hash' => 86400*30,
    'rootline' => 86400*30,
];
$redisDatabaseNumber = 0;
foreach ($cachesForRedis as $cacheName => $lifetime) {
    $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations'][$cacheName]['backend'] = \TYPO3\CMS\Core\Cache\Backend\RedisBackend::class;
    $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations'][$cacheName]['options'] = [
        'database' => $redisDatabaseNumber++,
        'hostname' => $redisHost,
        'port' => $redisPort,
        'defaultLifetime' => $lifetime
    ];
}

Extension Entwickler können eigene Caches in der Configuration/Services.yaml Datei einer Extension registrieren:

1
2
3
4
5
6
7
8
9
10

services:
  _defaults:
    autowire: true
    autoconfigure: true
    public: false

  cache.mycache:
    class: TYPO3\CMS\Core\Cache\Frontend\FrontendInterface
    factory: ['@TYPO3\CMS\Core\Cache\CacheManager', 'getCache']
    arguments: ['mycache']

Wie Du siehst werden viele Dinge an verschiedenen Stellen abgelegt, und wir werden sicherlich keine Äpfel und Birnen in denselben Korb legen. Schau wieder vorbei, wenn es um Caches geht, die außerhalb von TYPO3 liegen im nächsten Beitrag unserer Cache Serie.

Falls Du Hilfe brauchst, um das beste Cache Setup deiner TYPO3 Installation zu konfigurieren, melde Dich bei uns. Wir bei b13 lieben schnelle Websites und denken, dass TYPO3 das richtige CMS für Dich ist, um deine Website schnell zu laden.