Typo3 - Caching in Extensions - Versionsgeschichte

91.47.237.205: /* Links */

2010-05-03T18:50:27Z

Links

94.216.248.99: /* Praxis */

2010-04-12T10:08:36Z

Praxis

94.216.248.99 am 12. April 2010 um 09:34 Uhr

2010-04-12T09:34:26Z

94.216.248.99 am 12. April 2010 um 09:28 Uhr

2010-04-12T09:28:02Z

94.216.236.76 am 11. Januar 2010 um 16:21 Uhr

2010-01-11T16:21:42Z

94.216.236.76 am 11. Januar 2010 um 16:12 Uhr

2010-01-11T16:12:40Z

Neue Seite

Caching in TYPO3-Extensions

Michael Türk 29. Mai 2008

http://www.typo3-scout.de/2008/05/29/caching-in-typo3-extensions/

Wer einmal einen genaueren Blick auf die Abläufe im TYPO3-Frontend-Rendering geworfen hat, weiß, wie viele komplexe Vorgänge an der Ausgabe der TYPO3-Seiten beteiligt sind. Diese Komplexität steigt weiter, je mehr Extensions installiert sind. Würden TYPO3 Seiten bei jedem Aufruf neu aufgebaut, würde die Performance der Seiten erheblich Leiden und die Server hätten damit eher ihre Probleme. Außerdem funktioniert die Such-Indexierung nur dann, wenn die Inhalte zwischengespeichert werden.

Leider scheint das Caching an sich etwas zu wenig dokumentiert zu sein. Es finden sich immer wieder neue Extensions, welche die Caching-Mechanismen von TYPO3 nicht richtig einzusetzen verstehen. Dies liegt wahrscheinlich nicht zuletzt daran, dass die Schalter zum Aktivieren der Caching-Funktionalitäten recht gut versteckt und leicht zu übersehen sind.

Um die Performance von statischen Seiten zu verbessern, wird der fertig gerenderte HTML Code in der Datenbank abgelegt, um beim nächsten Abruf der Seite direkt aus der Datenbank geladen zu werden. Bei Extensions unterscheiden sich zwei verschiedene Vorgehensweisen:

1. Ein Großteil der Frontend-Plugins liefert bei gleichen Parametern immer gleiche Ergebnisse. Dies kennt man von News oder Shop-Systemen. Dies bedeutet, dass man die Ausgabe für verschiedene Parameter-Kombinationen jeweils im Cache ablegen kann, um sie bei der nächsten Anfrage beschleunigt ausgeben zu können.

2. Darüber hinaus existieren jedoch Erweiterungen, deren Ausgaben hochdynamisch sind. Zu dieser Gruppe zählen unter anderem Community-Features, deren Ausgabe minütlich wechseln kann, obwohl die Parameter gleich bleiben (oder gar keine Parameter angegeben werden). Hier würde Cache verhindern, dass der Benutzer alle neuen Informationen geliefert bekommt

Die Cache-Mechanismen werden zum an zwei verschiedenen Stellen der Extension ein- und ausgeschaltet. Dies ist zum Einen die Datei ext_localconf.php und zum anderen die Datei des Plugins selbst, die die Plugin-Base-Klasse enthält (welche in der Regel auf piX.php endet)

ext_localconf.php
t3lib_extMgm::addPItoST43($_EXTKEY,‘piX/class.tx_extensionname_piX.php’,‘_piX’,‘list_type’,1);

Der entscheidende Punkt in dieser Anweisung ist der letzte Parameter. Dieser wird im angegebenen Beispiel auf true gesetzt und das System somit angewiesen, die Ausgabe der Extension zu cachen.

t3lib_extMgm::addPItoST43($_EXTKEY,‘piX/class.tx_extensionname_piX.php’,‘_piX’,‘list_type’,0);

Im zweiten Fall wurde nun die Variable auf false gesetzt und die Ausgabe daher nicht zwischengespeichert.

class.extensionname_piX.php

Innerhalb der Extension kann nun noch festgelegt werden, ob das Plugin cHashing-Mechanismen zum Identifizieren gleicher Parameter-Kombinationen nutzen soll. cHashs werden durch den Typolink-Mechanismus erstellt, wobei die eingehenden Parametern zusammen mit dem geheimen internen Schlüssel zu einem Hash-Wert zusammengefasst werden. Dieser Mechanismus wird über das Setzen einer Klassenvariable erreicht:

var $pi_checkCHash = true;

Alternativ kann ein Plugin explizit als USER_INT Objekt ausgewiesen werden. Für diese wird in den gecachten Seiten ein Platzhalter hinterlegt, während die eigentliche Ausgabe der Extension erst zur Laufzeit der Webseite eingesetzt wird.
<pre>
function main($content,$conf) {
[...]
$this->pi_USER_INT_obj = 1;
[...]
}
</pre>

Ein häufig auftretender Fehler hierbei ist die Kombination der beiden letztgenannten Optionen. Allerdings widersprechen sich die beiden Konzepte, da beispielweise bei der Link-Generierung keine Cache Hashes gebildet werden, wenn ein Plugin einem USER_INT-Objekt entspricht. Um an dieser Stelle dynamische Ausgaben zu generieren, behelfen sich viele Entwickler mit der no_cache-Anweisung, die das Caching für die gesamte Seite deaktiviert. Dies bedeutet, dass die gesamte Seite von einer Indizierung ausgeschlossen wird und das Rendern der Seite erschwert wird. Von der Anweisung

$GLOBALS[‘TSFE’]->set_no_cache();

sollte in einer Live-Seite prinzipiell Abstand genommen werden.

Wie man sieht, sind die Anweisungen für Caching-Mechanismen eher übersichtlich, so dass die fachgerechte Einstellung des eigenen Frontend-Plugins keine allzu große Hürde darstellen sollte. In der Praxis gestaltet sich dies bisher leider noch zu oft als eine Hürde für Extensions mit viel Potential.

@@ Zeile 1: / Zeile 1: @@
 == Links ==
 http://www.typo3-handbuch.de/index.php?id=164
@@ Zeile 5: / Zeile 7: @@
 http://www.sk-typo3.de/COA_INT-in-Extensions.190.0.html
 == Caching in Typo3 ==

@@ Zeile 42: / Zeile 42: @@
 == Praxis ==
-Oft
+Eine typische Anforderung ist eine Extension mit Suchformular, eine Ergebnisliste und viele Detailansichten. Die Detailseiten sollen gecachet und durchsuchbar sein, aber die Form und die Ergebnisliste sollen nicht gecachet werden. Wie soll das gehen.
 == Caching in TYPO3-Extensions (Artikel)==

@@ Zeile 22: / Zeile 22: @@
 Damit das Plugin richtig als USER_INT Objekt behandelt wird muß folgendes beachtet werden:
-Klassenvariable
 === cHash ===
 Bei USER Objekten kommt das Caching mit  cHash zum Tragen. Dabei wird jede Seite mehrfach gespeichert. Und zwar gibt es für jede Kombination der POST/GET Parameter eine Version der Seite.
@@ Zeile 28: / Zeile 35: @@
 Sinnvoll ist dies wenn eine Seite bei einer Parameter-Kombination immer die gleichen Ergebnisse erzielt. Bei Hochdynamischen Seiten (Forum etc.) Wo sich dauernd etwas ändert ist das USER_INT Objekt vorzuziehen.
 == Praxis ==
 Oft

← Nächstältere Version		Version vom 12. April 2010, 09:28 Uhr
Zeile 1:		Zeile 1:
−	Caching in TYPO3-Extensions	+	== Links ==
		+	http://www.typo3-handbuch.de/index.php?id=164
		+
		+	http://www.sk-typo3.de/Richtiges-Cachen-mit-pi_base.188.0.html
		+
		+	http://www.sk-typo3.de/COA_INT-in-Extensions.190.0.html
		+
		+
		+	== Caching in Typo3 ==
		+	=== no_cache ===
		+	Das Caching in Typo3 läßt sich auf verschiedene Arten ausschalten:
		+	* no_cache=1 Parameter in der URL
		+	* Seiteneigenschaften
		+	* set no Cache Funktion
		+	* TypoScript
		+	Hierbei wird die komplette Seite bei jedem Aufruf neu berechnet. Die Performance nimmt dabei drastisch ab. Deshalb wird das Ausschalten des Seitencaches nicht empfohlen.
		+	=== USER_INT / COA_INT ===
		+	Bei USER_INT Objekten wird die Seite Gechachet und für das USER_INT Objekt ein Platzhalter hinterlegt. Es wird nur der Teil des USER_INT Objektes jedesmal neu berechnet.
		+
		+	Dies sollte nicht gemeinsam mit cHashing verwendet werden.
		+
		+	Damit das Plugin richtig als USER_INT Objekt behandelt wird muß folgendes beachtet werden:
		+
		+	Klassenvariable
		+	=== cHash ===
		+	Bei USER Objekten kommt das Caching mit cHash zum Tragen. Dabei wird jede Seite mehrfach gespeichert. Und zwar gibt es für jede Kombination der POST/GET Parameter eine Version der Seite.
		+
		+	Sinnvoll ist dies wenn eine Seite bei einer Parameter-Kombination immer die gleichen Ergebnisse erzielt. Bei Hochdynamischen Seiten (Forum etc.) Wo sich dauernd etwas ändert ist das USER_INT Objekt vorzuziehen.
		+
		+	== Praxis ==
		+	Oft
		+	== Caching in TYPO3-Extensions (Artikel)==

	Michael Türk 29. Mai 2008		Michael Türk 29. Mai 2008

@@ Zeile 11: / Zeile 11: @@
 Um die Performance von statischen Seiten zu verbessern, wird der fertig gerenderte HTML Code in der Datenbank abgelegt, um beim nächsten Abruf der Seite direkt aus der Datenbank geladen zu werden. Bei Extensions unterscheiden sich zwei verschiedene Vorgehensweisen:
-. Ein Großteil der Frontend-Plugins liefert bei gleichen Parametern immer gleiche Ergebnisse. Dies kennt man von News oder Shop-Systemen. Dies bedeutet, dass man die Ausgabe für verschiedene Parameter-Kombinationen jeweils im Cache ablegen kann, um sie bei der nächsten Anfrage beschleunigt ausgeben zu können.
+. Ein Großteil der Frontend-Plugins liefert '''bei gleichen Parametern immer gleiche Ergebnisse'''. Dies kennt man von News oder Shop-Systemen. Dies bedeutet, dass man die Ausgabe für verschiedene Parameter-Kombinationen jeweils im Cache ablegen kann, um sie bei der nächsten Anfrage beschleunigt ausgeben zu können.
-. Darüber hinaus existieren jedoch Erweiterungen, deren Ausgaben hochdynamisch sind. Zu dieser Gruppe zählen unter anderem Community-Features, deren Ausgabe minütlich wechseln kann, obwohl die Parameter gleich bleiben (oder gar keine Parameter angegeben werden). Hier würde Cache verhindern, dass der Benutzer alle neuen Informationen geliefert bekommt
+. Darüber hinaus existieren jedoch Erweiterungen, deren '''Ausgaben hochdynamisch''' sind. Zu dieser Gruppe zählen unter anderem Community-Features, deren Ausgabe minütlich wechseln kann, '''obwohl die Parameter gleich bleiben''' (oder gar keine Parameter angegeben werden). Hier würde Cache verhindern, dass der Benutzer alle neuen Informationen geliefert bekommt
-Die Cache-Mechanismen werden zum an zwei verschiedenen Stellen der Extension ein- und ausgeschaltet. Dies ist zum Einen die Datei ext_localconf.php und zum anderen die Datei des Plugins selbst, die die Plugin-Base-Klasse enthält (welche in der Regel auf piX.php endet)
+Die Cache-Mechanismen werden zum an '''zwei verschiedenen Stellen''' der Extension ein- und ausgeschaltet. Dies ist zum Einen die Datei '''ext_localconf.php''' und zum anderen die Datei des Plugins selbst, die die '''Plugin-Base-Klasse''' enthält (welche in der Regel auf piX.php endet)
 Der entscheidende Punkt in dieser Anweisung ist der letzte Parameter. Dieser wird im angegebenen Beispiel auf true gesetzt und das System somit angewiesen, die Ausgabe der Extension zu cachen.
-       t3lib_extMgm::addPItoST43($_EXTKEY,‘piX/class.tx_extensionname_piX.php’,‘_piX’,‘list_type’,0);
+<pre> t3lib_extMgm::addPItoST43($_EXTKEY,‘piX/class.tx_extensionname_piX.php’,‘_piX’,‘list_type’,0);
+</pre>
 Im zweiten Fall wurde nun die Variable auf false gesetzt und die Ausgabe daher nicht zwischengespeichert.
- class.extensionname_piX.php
+'''class.extensionname_piX.php'''
-Innerhalb der Extension kann nun noch festgelegt werden, ob das Plugin cHashing-Mechanismen zum Identifizieren gleicher Parameter-Kombinationen nutzen soll. cHashs werden durch den Typolink-Mechanismus erstellt, wobei die eingehenden Parametern zusammen mit dem geheimen internen Schlüssel zu einem Hash-Wert zusammengefasst werden. Dieser Mechanismus wird über das Setzen einer Klassenvariable erreicht:
+Innerhalb der Extension kann nun noch festgelegt werden, ob das Plugin '''cHashing-Mechanismen zum Identifizieren gleicher Parameter-Kombinationen''' nutzen soll. cHashs werden durch den Typolink-Mechanismus erstellt, wobei die eingehenden Parametern zusammen mit dem geheimen internen Schlüssel zu einem Hash-Wert zusammengefasst werden. Dieser Mechanismus wird über das Setzen einer Klassenvariable erreicht:
   var $pi_checkCHash = true;
-Alternativ kann ein Plugin explizit als USER_INT Objekt ausgewiesen werden. Für diese wird in den gecachten Seiten ein Platzhalter hinterlegt, während die eigentliche Ausgabe der Extension erst zur Laufzeit der Webseite eingesetzt wird.
+'''Alternativ''' kann ein Plugin explizit '''als USER_INT Objekt''' ausgewiesen werden. Für diese wird in den gecachten Seiten ein Platzhalter hinterlegt, während die eigentliche Ausgabe der Extension erst zur Laufzeit der Webseite eingesetzt wird.
 <pre>
 function main($content,$conf) {