TYPO3 Performance and Caching

Transkript

1 TYPO3 Performance and Caching Bernhard Kraft PHP/TYPO3 Freelancer / TYPO3 Core Team Member

2 TYPO3 Performance and Caching 1. Problemstellung Oder: Warum braucht meine Seite 1 Minute zum laden? 2. Caching Mechanismen Oder: Gehen Sie nicht über Start, warten Sie nicht 1 Minute! 3. Konfigurations Einstellungen Oder: Wie mache ich meine TYPO3 Seite so RICHTIG langsam? 4. Einstellungen überprüfen Oder: Klappt das jetzt endlich alles? 5. Funktionsweise optimieren Oder: Keep it simple. Ausser der Kunde will es unbedingt kompliziert. 6. Publishing, Static File-Cache, und Extensions Oder: Warum nicht gleich html Dateien erstellen? 7. Zukunftsmusik Oder: Geht da noch was?

3 1. Problemstellung Oder: Warum braucht meine Seite 1 Minute zum laden? 1.1 TYPO3 generiert den Inhalt der im FE angezeigten Seiten ZUR LAUFZEIT. 1.2 Es wird eine grosse Anzahl an Überprüfungen und Datenbankabfragen beim Rendern einer Seite abgearbeitet. 1.3 Der Inhalt der Seiten, die Inhaltselmemente, werden durch eine aufwendige Struktur aus TypoScript, TSConfig und PHP durchgejagt, welche erst die Dynamik von TYPO3 ergibt. 1.4 FE Ablauf-Diagramm (Flowchart) 1.5 Extensions können unter Umständen komplexe Queries, Rendering Vorgänge oder andere zeitaufwendige Operationen durchführen.

4 1.1 TYPO3 generiert den Inhalt der im FE angezeigten Seiten ZUR LAUFZEIT Beim Aufrufen der index.php wird der Rendering Prozess gestartet. Eine grosse Anzahl an php Dateien wird in einer Art Kettenreaktion inkludiert. Bei jedem Aufruf müssen die PHP Konfigurations-Dateien (localconf.php) und zugehörige Dateien geparsed und abgearbeitet werden. Inhalte der Seite sind ständig aktuell. Es (sollte) keine toten Links oder Punkte im Menü geben welche nicht aufrufbar oder leer sind. Es kann beim Rendering Rücksicht auf unterschiedliche Parameter wie Browser, IP-Adresse (Land, Region), Sprache oder andere Eigenschaften genommen werden, welche erst bei aufruf der Seite durch den Browser bekannt sind.

5 1.2 Es wird eine grosse Anzahl an Überprüfungen und Datenbankabfragen beim Rendern einer Seite abgearbeitet. Es wird überprüft ob FE und/oder BE-User eingeloggt sind. BE-User FE-Editing Dazu müssen die Session-Tables abgefragt werden. Jede Menge der Einstellungen in TYPO3_CONF_VARS welche über das Install Tool vorgenommen wurden, führen zu vielen if's und mehr Code um alle Fälle einzuschliessen. Der TypoScript Cache wird überprüft. Der Seiten-Cache wird abgefragt. TypoScript Templates, Seiten, die Root-Line, Seiten-Inhalte, etc. werden aus der Datenbank geladen und TypoScript rendert diese Inhalte.

6 1.3 Inhalte werden durch TypoScript, TSConfig und PHP durchgejagt Eine Seite wird von einem PAGE TypoScript Objekt gerendert. Dazu wird viel Programmcode in class.tslib_fe.php (GLOBALS[TSFE]) abgearbeitet. Inhaltselemente einer Seite werden von CONTENT oder RECORDS (TemplaVoila) TypoScript Objekten aus der Datenbank abgerufen. Inhaltselmente werden durch eine aufwendige Struktur des TypoScript Konstruktes tt_content in html code umgewandelt. TSConfig kann Parameter auf viele der Rendering Prozesse, speziell der Darstellung von RTE Elementen nehmen. Der eigentliche, durch TypoScript gesteuerte, Programmablauf findet jedoch durch PHP-Skripts statt.

7 FE Ablauf Diagramm Flow-Chart

8 Laufzeiten O(1)... konstante Laufzeit $a = $b + $c; O(n)... linear - Laufzeit steigt linear mit n for ($i = 0; $i < $n; $i++) { $var[$i] = $var[$i] * 10 } O(n²)... quadratisch - Laufzeit steigt quardatisch mit n for ($i = 0; $i < $n; $i++) for ($j = 0; $j < $n; $j++) { $var[$i][$j] = $i*$j }

9 Funktionsweise... ungefähr... ;) Laufzeitdiagnose O( )

10 1.5 Extensions können unter Umständen komplexe Queries, Rendering Vorgänge oder andere zeitaufwendige Operationen durchführen. Durch die Option Extensions einzufügen sind prinzipiell keine Grenzen gesetzt. Es können keine direkten Aussagen über die Laufzeiten von eingefügten Plugins gemacht werden. Auch Hooks und/oder durch XCLASS veränderter Basis-Code können das Laufzeitverhalten ändern.

11 2. Caching Mechanismen Oder: Gehen Sie nicht über Start, warten Sie nicht 1 Minute! 2.1 Was bedeutet Caching? 2.2 Wann und Wo setzt TYPO3 Caches ein? 2.3 TypoScript Cache 2.4 Page bzw. Content Cache 2.5 Menü Cache 2.6 Wo kann Caching schaden?

12 2.1 Was bedeudet Caching Caching bedeudet das Inhalte, bzw. Daten welche bereits geparsed oder anderweitig verarbeitet wurden, in einer Art und Weise gespeichert werden welche ein schnelles abrufen, und neuerliches verwenden erlauben. Wikipedia über Cache : Cache [kæ ʃ] bezeichnet in der EDV eine Methode, um Inhalte, die bereits einmal vorlagen, schneller ein zweites Mal zu beschaffen. [...] Gründe für den Einsatz eines Caches sind ein (relativ gesehener) langsamer Zugriff auf ein Hintergrund- Medium oder ein relativ hoher Aufwand, oft benötigte Daten neu zu generieren.

13 2.2 Wann und Wo setzt TYPO3 Caches ein? Oft werden mit TYPO3 Websiten dargestellt, welche einen Inhalt anzeigen, welcher sich nur nach Modifikationen durch einen Redakteur ändert. Die generierten HTML Daten können in einem Seiten-Cache (cache_pages) gespeichert werden um beim nächsten Aufruf der Seite ohne grosse Umwege zur Verfügung zu stehen. TypoScript Code, welcher für eine Seite gültig ist. Kann/muss auch für die Generierung von Sub-Seiten verwendet werden, es sei denn diese Sub-Seiten verwenden zusätzliche TypoScript Templates. Der geparste TypoScript Code wird in Form serialisierte Daten zwischengespeichert (cache_hash) Bild-Informationen für mit dem GIFBUILDER erstellte Bilder (cache_imagesizes) und Informationen über _INT Objekte (cache_pagesection) werden ebenfalls gecached.

14 2.3 TypoScript Cache TYPO3 cached bereits einmal geparsten TypoScript Code in der Datenbank Tabelle cache_hash Seiten für welche die selben TypoScript Templates gültig sind verwenden den selben Cachen Entry. Aufgefundene Conditions werden erkannt und in einem Array gespeichert, um beim Aufruf einer Seite erneut gematcht werden zu können. Nach ändern eines TS-Templates wird dies vor dem nächsten generieren einer Seite (anhand der timestamp des TS-Template Records) erkannt. Der TypoScript Code wird neu geparsed. VORSICHT: Änderungen von per <INCLUDE_TYPOSCRIPT... eingebundene Dateien werden nicht erkannt.

15 2.4 Page bzw. Content Cache Der gerenderte Content einer Seite wird in der Datenbank Tabelle cache_pages gecached. Bei nochmaligem Aufruf einer Seite (mit den selben Parametern) wird der Inhalt aus dem Cache geliefert. Vor dem ausliefern der Daten auf dem Cache, werden die gespeicherten Conditions aus dem TypoScript erneut evaluiert. Nur bei selbem Zustand der Condition Evaluierungen wird die Seite aus dem Cache geliefert. Es gibt insgesamt 3 Parameter welche bestimmen ob eine Seite aus dem Cache geliefert wird: 1. Conditions 2. FE-User-Gruppen Zugehörigkeit 3. Page-Expiration Time bzw. Start/Stop Zeiten

16 2.5 Menü Cache Mit HMENU / TMENU (etc.?) generierte Menüs werden ebenfalls gecached. Ein Menü wird aufgrund der dargestellten Elemente und der TypoScript Konfiguration aus dem Cache bezogen, oder bei Änderungen erneut generiert. Beim Leeren der Caches wird auch der Menü-Cache geleert. Die Menü-Cache Einträge werden ebenfalls in der Datenbank Tabelle cache_hash gespeichert.

17 2.6 Wo kann Caching schaden? Bei Seiten mit vielen _INT Objekten Bei Seiten mit endlosen (unterschiedlichen) Links auf die selbe Seite, jedoch mit unterschiedlichen Parametern (z.b. bei einem Kalender mit vce_calendar) Das Caching sollte eventuell unter folgenden Umständen deaktiviert werden: * Bei Seiten welche bei jedem Laden unterschiedliche Inhalte, wize zum Beispiel Random-Elemente anzeigen müssen * Bei Seiten auf welchen Formulare oder andere User-Eingabedaten verarbeitet werden müssen, aber die zuständigen Extensions/Plugins

18 3. Konfigurations Einstellungen Oder: Wie mache ich meine TYPO3 Seite so RICHTIG langsam? 3.1 Kein Page-Cache 3.2 Kein TypoScript-Cache 3.3 Durch Links 3.4 Durch fiese Programmierung

19 3.1 Kein Page-Cache Page Cache deaktivieren: config.no_cache = 1 page.config.no_cache = 1 Auch durch setzen des Flags No Cache bzw. Kein Caching in den Seiten Eigenschaften einer Seite. Durch Aufrufen von $GLOBALS['TSFE']->set_no_cache() aus Extensions oder User-Functions Durch den GET/POST Parameter &no_cache=1

20 3.2 Kein TypoScript Cache Per TS-Config TypoScript Cache deaktivieren: admpanel.override.tsdebug.forcetemplateparsing = 1 Oder durch setzen von forcetemplateparsing direkt in class.tslib_fe.php VORSICHT: Aufpassen bei Verwendung von dynamischen TypoScript

21 3.3 Durch Links Wenn Links auf die Seiten den GET/POST Parameter &no_cache=1 beinhalten wird der Page-Cache deaktiviert (nur für diesen einen Aufruf) config.linkvars = no_cache Links ohne chash Parameter. Über den chash Paramter gibt es ein gute Erklärung auf typo3.org: Bei manchen UI Elementen kann es zu einer endlosen Auflistung kommen: Links welche immer wieder auf die selbe Seite führen, aber mit unterschiedlichen Parametern. Bsp: vce_calendar : In der Kalendar Ansicht gibt es Links zum nächsten und vorherigen Monat. Diese Links werden von search-engine bots so weit als möglich verfolgt und können riesigen Daten-Müll in cache_pages erzeugen.

22 3.4 Durch fiese Programmierung Prinzipielles aufrufen von $GLOBALS['TSFE']->set_no_cache(); Löschen der ganzen Inhalte (oder grosser Teile) der Tabelle cache_pages bei einer Änderung. Kein sauberes verwenden der Link API zum erstellen von Links: pi_getpagelink, pi_linktopage, pi_linktp, pi_linktp_keeppivars, pi_linktp_keeppivars_url, pi_list_linksingle cobj->typolink, cobj->typolink_geturl

23 4. Einstellungen überprüfen Oder: Klappt das jetzt endlich alles? 4.1 Überprüfen im adminpanel 4.2 Direkt Einträge in mysql Datenbank überprüfen 4.3 Logging aktivieren und kontrollieren 4.4 Extensions berücksichtigen

24 4.1 Überprüfen im adminpanel Im adminpanel kann das Caching per Checkbox ein und ausgeschalten werden. Es kann überprüft werden wieviele Einträge sich für die aktuelle Seite im Cache befinden. Auch das Template Parsing kann im adminpanel auf force gestellt werden.

25 4.2 Direkt Einträge in mysql Datenbank überprüfen Die Anzahl der Einträge in der cache_pages und cache_hash Tabelle kann überprüft werden. Entweder direkt über die mysql shell - oder auch über phpmyadmin Um das Caching Verhalten zu ermitteln sollte überprüft werden wie sich die Anzahl der Einträge beim aufrufen von Seiten ändernt.

26 4.3 Logging aktivieren und kontrollieren Das Logging kann über das Install Tool aktiviert werden. Es kann in eine Datei, in das syslog des Systems, in das PHP-Error Log, oder sogar per Mail geloggt werden. Option: TYPO3_CONF_VARS[SYS][systemLog] In der Log-Datei sind Einträge zu finden wie: :16 - cms: $TSFE->set_no_cache() was triggered by typo3conf/ext/kb_display/pi_cached/class.tx_kbdisplay_pi_cached.php on line 76. Caching is disabled!

27 4.4 Extensions berücksichtigen Extensions können den Cache deaktivieren. (Siehe Logs) Extensions können Cache Einträge löschen Manche Extensions sind als USER_INT Objekte ausgeführt (Siehe TypoScript Object Browser) Manche Extensions implementieren eigene Caches.

28 5. Funktionsweise optimieren Oder: Keep it simple. Ausser der Kunde will es unbedingt kompliziert. 5.1 Keine _INT Objekte wenn möglich, JavaScript, AJAX 5.2 FE Benutzergruppen klug auslegen 5.3 Wenig Conditions 5.4 Bei eigenen Extensions das reg1 Feld des Seiten-Caches verwenden (google: typo3 reg1) 5.5 Cache-Headers + Reverse Proxies

29 5.1 Keine _INT Objekte wenn möglich Wenn nicht unbedingt notwendig keine _INT TypoScript Objekte verwenden. In den meisten Fällen ist es besser, die eigene Extension einen Eintrag aus der cache_pages Tabelle löschen zu lassen, als ein _INT Objekt zu verwenden. In manchen Fällen ist es sogar sinnvoll die cache_pages Einträge einer ganzen Seite löschen zu lassen, anstatt ein _INT Objekt zu verwenden. Merken: _INT Objekte sind böse!!! Oft können _INT Objekte, wie z.b. zur Anzeige der aktuellen Uhrzeit und Datum durch JavaScript's umgangen werden. Wenn z.b. der aktuelle Username, und andere User-Spezifische Daten angezeigt werden, ist es auch möglich, diese vom Server per AJAX nachzuladen. Wenn das serverseitige AJAX Skript einen kleine Footprint hat ist dies immer noch schneller als etliche _INT Objekte.

30 5.2 FE Benutzergruppen klug auslegen Eine grosse Anzahl an FE-Benutzergruppen führt zu vielen Cache Einträgen pro Seite. Wenn FE-Benutzergruppen in verschiedenen Kombinationen vorkommen, gibt es unter Umständen für jede Kombination einen Cache Eintrag pro Seite. 4 FE-Benutzergruppen 16 Mögliche Kombinationen!!! (n=4, 2 n =16)

31 5.3 Wenig Conditions Auch Conditions wenn möglich vermeiden. Browser Weichen für CSS (IE/FF) können zum Beispeil auch über Conditional CSS realisiert werden: <!--[if lte IE 7]>... <![endif]-->... CSS für IE<7 Wenn Conditions nur auf einer Seite (z.b. Startseite) benötigt werden, sicherstellen, dass diese auf Unterseiten nicht auch evaluiert werden (oder zumindest nicht bei mehreren Aufrufen unterschiedlich) Bsp: 5 Conditions bei welchen es bei jeder möglich ist bei einem Aufruf mit true/oder false evaluiert zu werden (die compatversion Condittion wird im Normalfall immer gleich evaluiert): 2 5 = 32 Fälle = 32 Einträge im Cache (pro Seite) Kommen dann noch z.b. 4 FE-Benutzergruppen ins Spiel, bei welchen ein FE- Benutzer jede belibige Kombination aus diesen haben kann, so gibt es: 2 5 * 2 4 = = 2 9 = 512 Fälle = 512(!!!) Einträge im Cache (pro Seite)

32 5.4 Bei eigenen Extensions das reg1 Feld des Seiten-Caches verwenden In der cache_pages Tabelle gibt es ein Feld reg1. Dieses kann verwendet werden um einen Cache-Eintrag zu taggen. Wenn es auf einer TYPO3-Seite (selbe id ) mehrere Einträge gibt welche dargestellt werden sollen. Z.B. auf einer News-Detail Seite News-Artikel welche dargestellt werden sollen. So werden diese Artikel über einen Parameter in der URL selektiert. In das reg1 Feld der cache_pages Tabelle kann nun z.b. die UID dieser Artikel gespeichert werden, um z.b. beim ändern eines Artikel nicht alle Cache- Einträge für die gesamte Seite aus dem Seiten Cache entfernen zu müssen, sondern nur gezielt einen einzelnen Cache-Eintrag.

33 5.4 Cache-Headers und Reverse Proxies Wenn eine Seite nicht viele variable Elemente, wie _INT Objekte, FE-User spezifische Elemente etc. enthält, kann auch ein Reverse Proxie als Seiten- Cache eingesetzt werden. Im TypoScript ist dies durch aktivieren der Option: config.sendcacheheaders = 1 Siehe TSRef für Dokumentation dieses Features.

34 6. Publishing, Static File-Cache, und Extensions Oder: Warum nicht gleich html Dateien erstellen? 6.1 Publishing 6.2 Static File-Cache 6.3 Extensions 6.4 Manuelles Publishing: httrack, wget & Co

35 6.1 Publishing Unter Publishing versteht man gemeinhin das erstellen einer statischen (html) Version der aktuellen Seite. Eventuell sind mit dem Prozess des Publishing auch Review-Prozesse verbunden. Publishing kann auch das transferieren der erstellten statischen Versionen auf einen Live-Server bedeuten TYPO3 verfügt über ein eingebautes Publishing System, es gibt jedoch auch Publishing System als Extensions. Auch automatische Publishing Systems sind verfügbar. Dies wird jedoch eher als Static File Cache bezeichnet.

36 6.2 Static File-Cache Als Static File Cache wird die Methode bezeichnet, den Seiten Cache nicht in einer Datenbank Tabelle abzulegen, sondern als Dateien im Dateisystem. Siehe Konfigurations Option: TYPO3_CONF_VARS[FE][pageCacheToExternalFiles] Bringt nicht immer Vorteile mit sich (viele Dateien in einem Verzeichniss) Datenbank-Verbindung wird trotzdem aufgebaut

37 6.3 Extensions static_file_cache Es gibt z.b. eine Extension static_file_cache und static_file_publish welche dem integrierten Publishing System von TYPO3 überlegen sind. Siehe dazu Artikel: Vorteile: Am Server liegen komplett statische Seiten. Nachteile: Das Publizieren passiert manuell Es können keine FE-User, Conditions, Page-Expires etc. berücksichtigt werden.

38 6.3 Extensions kb_quickfe Die Extension liefert ein striped-down index.php welches das normale index.php im web-root ersetzen soll (muss manuell erledigt werden). Dieses alternative index.php beginnt sofort damit die 3 relevanten Parameter: Conditions, FE-Gruppen Zugehörigkeit, Expire-Times auszuwerten, und liefert je nachdem ob es dafür eine Cache-Datei gibt einfach den Inhalt dieser Datei, oder ruft die normale index_ts.php von TYPO3 auf, um die Seite generieren zu lassen. Vorteile: Auch Conditions, FE-Gruppen Zugehörigkeit und Page-Expire Times können berücksichtigt werden. Wenn die Seite _INT Objekte beinhaltet gibt es ein Fallback auf die normale index_ts.php Es muss nicht das komplette Set an TYPO3 PHP Files inkludiert werden. Nachteile: Es ist immer noch PHP mit im Spiel. Wenn auf das Fallback zurückgegriffen wird kommt es zu einem geringen Overhead

39 6.4 Manuelles Publishing: httrack, wget & Co Es kann natürlich mit einem einfachen Webseiten-Kopier Programm wie httrack oder wget eine Kopie der Website von einem dev-server erstellt werden, und die statischen Files können auf den Server überspielt werden. Nachteile: Funktioniert nicht in allen Fällen, keine dynamischen Elemente wie Kontakt-Formular, etc. Spiegeln und Upload muss manuell durchgeführt werden. Vorteile: Ohne grossen aufwand bei einfachen Seiten, kann z.b. für Präsentationen verwendet werden wenn kein Internet vorhanden ist

40 7. Zukunftsmusik Oder: Geht da noch was? 7.1 E-Accelerator, ioncube, Zend Cache, etc. 7.2 TYPO3 Application server 7.3 Caching Algorythmus Optimierung (Keine Redundanz == Weniger Seiten im Cache) 7.4 Nur Notwendige PHP-Includes 7.5 Kleinere Klassen (Das Monster: t3lib_div) 7.6 Apache module für static file-caching 7.7 TYPO3 Compiler

41 TYPO3 Performance and Caching Bernhard Kraft PHP/TYPO3 Freelancer / TYPO3 Core Team Member und Student an der Uni-Wien (Molekulare Biologie)