Die Performance von TYPO3 steigern - Teil I

Die einfachste Möglichkeit, Leistung zu steigern, ist natürlich, Leistungsbedarf gar nicht erst entstehen zu lassen. Das heißt für TYPO3: Aufräumen. Nicht benötigte Extensions sollten auf jeden Fall aus dem System entfernt werden. Denn auch ungenutzte Erweiterungen haben Einfluss auf das System. Zum Einen vergrößern sie die Datenbank und verlangsamen damit die Zugriffe und erhöhen den Speicherverbrauch. Zum Anderen hängen sich manche Extensions in die Code-Ausgabe ein.

Werden mehrere Seiten mit TYPO3 auf einem Server betrieben, sollte auf jeden Fall eine gemeinsame Code-Basis benutzt werden. Auch das sorgt dafür, den Speicherverbrauch des Systems so gering wie möglich zu halten.

1. TYPO3-Cache optimieren

Der zweite Ansatzpunkt in TYPO3 ist der Cache. Dass er eingeschaltet sein sollte, ist eigentlich selbstverständlich. Denn Seiten, die schon fertig gerendert sind, belasten das System ungleich weniger als neu generierte. Trotzdem passiert es vor allem beim Übergang von der Test- in die Produktionsphase immer wieder, dass die Cache-Konfiguration nicht angepasst wird.

Die richtige Strategie für den Cache ist relativ einfach: Grundsätzlich sollte der Cache aktiv sein und nur für Seiten, die sich sehr häufig ändern, abgeschaltet werden. Das passiert entweder im Backend-Formular der Seite oder über Typoscript.

Die Cache-Einstellungen lassen sich gezielt für jede Seite setzen

Wichtig für das Verständnis des TYPO3-Cache ist, dass er eine Datenbank-Tabelle nutzt. Wird also eine Seite aufgerufen, die noch nicht im Cache abgelegt wurde oder deren Cache abgelaufen ist, so erstellt TYPO3 ein HTML-Abbild in der Tabelle. Diese Tabelle wird aber nicht automatisch geleert. Ein Eintrag wird nur dann geändert, wenn die zugehörige Seite neu angefordert wird.

Für einen Webauftritt mit sehr vielen Seiten, aber wenigen Abrufen pro Seite kann das bedeuten, dass die Cache-Tabelle sehr groß wird, die meisten Einträge aber bereits ungültig sind. Trotzdem verlangsamen sie die Cache-Verwaltung. Für diesen Fall gibt es die Möglichkeit, die HTML-Abbilder nicht in der Datenbank abzulegen, sondern als Dateien. Die Einstellung dazu erfolgt im Install-Tool mit der Option

[FE][pageCacheToExternalFiles] = 1

Der Punkt, ab dem diese Option sinnvoll wird, lässt sich allerdings nur durch Messung am aktuellen System bestimmen. Denn die Beschleunigung der Cache-Verwaltung konkurriert mit der Verzögerung durch den Dateizugriff.

2. Browser-Cache und Proxy-Server

Eine andere Möglichkeit, Typo3 vom Erstellen der Seiten zu entlasten, ist, sie gar nicht erst ausliefern zu müssen, weil sie schon vor Ort sind, etwa im Cache des Browsers oder eines Proxy-Servers. TYPO3 wird in diesem Fall für das Erstellen und Ausliefern der Seite gar nicht erst bemüht.

Gesteuert wird dieses Zwischenspeichern mithilfe der so genannten Cache Control Headers. Die Option, diese Header zu senden, gibt es in TYPO3 seit der Version 3.8. Um sie zu aktivieren, wird im Typoscript-Setup die Zeile

config.sendCacheHeaders = 1

eingefügt.

Damit TYPO3 die Header sendet, müssen einige Bedingungen erfüllt sein:

Ganzen Artikel lesen...

Die Seite muss bereits von TYPO3 gecacht worden sein.
Auf der Seite dürfen keine Objekte vom Typ *_INT oder *_EXT vorhanden sein (beispielsweise USER_INT)
Der Besucher ist weder im Front- noch im Backend angemeldet.

Allerdings bleibt damit ein spezielles Problem ungelöst. Geht ein nicht angemeldeter Benutzer auf eine Seite, wird sie mit Cache Control Headers ausgeliefert und damit im Browser-Cache abgelegt. Meldet sich der Benutzer nun an und geht erneut auf die Seite, so erhält er erneut die Seite aus dem Cache statt der aktuellen - die eventuell nach der Anmeldung andere Inhalte hat.

Dieses Problem lässt sich umgehen, indem man die Cache Control Header nur für Seiten ausliefert, auf denen kein Login möglich ist. Die entsprechenden Seiten werden im Backend entsprechend gekennzeichnet.

Außerdem wird im Setup die Option

config.sendCacheHeaders_onlyWhenLoginDeniedInBranch = 1

gesetzt.

Ist die Extension realurl im Einsatz (was fast immer für erfolgreiche Cache-Strategien nötig ist), lässt sich das Probleme auch lösen, indem mittels realurl für angemeldete User andere Urls vergeben werden als für nicht angemeldete.

Browser-Caching hat aber einen Nachteil für den Betreiber einer Website: Wenn der Browser die Seite nicht neu holt, entsteht auch kein Eintrag im Log des Webservers und damit werden die Abrufzahlen verfälscht.

Ihr volles Potenzial können die Cache Header daher nur mit einem Proxy-Server entfalten, der die TYPO3-Ausgaben zwischenspeichert und unter der Kontrolle des Anbieters der Website steht. Eine solche Konfiguration ist auch mit nur einem Rechner als Webserver möglich, beispielsweise über mod_proxy, ein Modul von Apache, oder mit Squid, einem Proxy, der in jeder Linux-Distribution enthalten ist.

3. Statische Dateien erzeugen

Bei aktivem TYPO3-Cache holt TYPO3 den Inhalt der Seite aus der Datenbank oder einer externen Datei. Führt man diesen Gedanken weiter, könnten doch in letzterem Fall gleich unter Umgehung von TYPO3 die statischen Seiten ausgeliefert werden. Der Performance-Gewinn in diesem Fall ist extrem hoch. Weder TYPO3 noch PHP noch die Datenbank müssen für eine Auslieferung bemüht werden. Das kann eine Website mit einem hohen Anteil an statischen Inhalten um einen Faktor 200 und mehr beschleunigen.

Eine Möglichkeit, solche statischen Dateien automatisch anzulegen, bietet die Extension crawler, die auch im Zusammenhang mit indexed_search gute Dienste leistet. Um diese Dateien dann auch abzurufen, muss eine Erweiterung wie realurl installiert sein, damit die Links korrekt generiert werden, und die Rewrite-Funktionen des Servers müssen entsprechend angepasst werden, damit die Seiten direkt geliefert werden können.

Neben crawler gibt es auch andere Erweiterungen, die sich auf das Erstellen und Verwalten der statischen Seiten spezialisiert haben, beispielweise nc_staticfilecache oder fl_staticfilecache. Die Installation und Konfiguration ist sehr einfach. Als Voraussetzung für den Einsatz muss realurl installiert sein oder die Option simulateStaticDocuments aktiviert werden. Empfohlen wird außerdem das Apache-Modul mod_expires, um die Cache Control Headers richtig zu steuern. Nach der Installation werden standardmäßig alle Seiten als statische Dateien abgelegt. Für einzelne Seiten lässt sich dies im Bereich Erweitert der Seite abschalten.

nc_staticfilecache lässt sich sehr einfach steuern.

4.Persistente Datenbankverbindung abschalten

TYPO3 nutzt für die Verbindung zur Datenbank standardmäßig persistente Verbindungen. Das heißt, dass Datenbankverbindungen nicht mit Ende des Skripts abgebaut werden. Greift ein neues Skript auf die Datenbank zu, prüft PHP, ob bereits eine persistente Verbindung besteht, und nutzt diese erneut. In der Theorie verspricht dies eine Verbesserung der Leistung.

In der Praxis sieht die Situation etwas anders aus, denn persistente Verbindungen bergen einige Tücken. So wird beispielsweise bei hochfrequentierten Seiten schnell die Anzahl maximal erlaubter Verbindungen überschritten, weil sie nicht sofort wieder geschlossen werden.

Weitere Probleme treten auf, wenn ein Skript abstürzt, aber eine Tabelle zum Bearbeiten gesperrt hat (Table Lock). Die Sperre wird dann nicht aufgehoben, und dadurch kommt kein anderes Skript, das dieselbe Verbindung nutzt, an die Tabelle heran. Ein ähnliches Problem kann bei Transaktionen auftreten.

Persistente Verbindungen sind also nicht unproblematisch. Gleichzeitig ist der Leistungsgewinn sehr gering bis nicht vorhanden, wenn Datenbank und Webserver auf einer Maschine laufen.

Die Empfehlung lautet daher klar, in einem solchen Setup persistente Verbindungen abzuschalten. Dies kann entweder global in der php.ini geschehen mit

mysql.allow_persistent = Off

oder in TYPO3 bei der Installation. Die Einstellung verbirgt sich unter der Option [SYS][no_pconnect].

Persistente Verbindungen in Typo3 abschalten