Serendipity hat das Problem, ohnehin schon relativ unperformant zu sein. Mit der Einführung von Smarty hat sich das Problem soweit verschärft, das jetzt endlich über Caching nachgedacht wird. Statt mich auf ewige Diskussionen in holprigem Englisch auf der Mailingliste einzulassen, versuche ich hier einfach mal die Konzepte von Caching zu erklären.
In s9y löst jeder einzelne Seitenabruf eine Vielzahl von Datenbankabfragen aus. Eine Reihe von Plugins laufen über den aus der Datenbank gelesenen Content, bevor er letztendlich beim Nutzer ausgegeben wird.
Caching dient zunächst einmal dazu, Daten so nah am Nutzer wie möglich zu speichern. Ziel davon ist, wiederholte Generierung und Transport von Daten zu vermeiden. Daten, die sich nicht verändern, am Beispiel von s9y also Artikel, die Ausgabe von einzelnen Plugins usw. können gecached werden. Somit ist es nicht mehr nötig, bei jedem Abruf eines Artikels die Datenbank zu fragen. Lediglich bei der Änderung eines Artikels muss dem Cachingsystem mitgeteilt werden, das sich dieser Artikel verändert hat.
Unabhängig der konkreten Implementierung eines Caches geht es zunächst darum, zu verstehen wie Caches überhaupt arbeiten und was zu cachen ist. Es ist wichtig zu verstehen, was der Zustand eines Objektes ist und was diesen Zustand ausmacht bevor man entscheiden kann, ob man in cachen möchte. Ist er von einer bestimmten Dauer abhängig? Ist er vom Zustand eines anderen Objektes abhängig?
In der Regel hat der Zustand etwas mit den Daten selbst und deren Status zu einem bestimmten Zeitpunkt zu tun. Diese Daten können für einem einzelnen User zu einem Zeitpunkt relevant sein oder für immer und ewig und fast alle Bestand haben.
Es ist wichtig, zu verstehen, wie lange dieser Status anhält, also wann er beginnt und wann er endet. Ein Status kann abgelaufen sein, bevor der Nutzer die Daten überhaupt erhalten hat. Solche Daten zu cachen ist natürlich widersinnig und es gilt sich darüber klarzuwerden, was überhaupt cachebar ist - und noch viel wichtig, wie man solch suizidales Verhalten verhindern oder umschiffen kann. In einigen Fällen kann es auch sinnvoll sein, suizidale Daten für einen bestimmten Zeitraum doch aus dem Cache zu verwenden, obwohl sie schon abgelaufen sind.
Für s9y ist zum Beispiel ganz klar, das es absolut keinen Sinn macht, komplette HTML-Seiten zu cachen. Selbst für HTML-Fragmente ist das schwierig, da damit unter bestimmten Bedingungen das mächtige Plugin-System ausser Kraft gesetzt wird.
Meiner Ansicht nach reduzieren sich die Möglichkeiten auf folgende Punkte:
Schritt eins wäre also, die Daten nach dem Auslesen aus der Datenbank zu cachen. Werden Daten in der Datenbank verändert oder hinzugefügt, sind die Status der entsprechenden Cache-Identifier auf abgelaufen zu setzen.
Auf diese Weise können noch allerhand Schweinereien wie die Markierung von bestimmten Passagen durch das Searchhighlight-Plugin vor der eigentlichen Ausgabe erfolgen. Andere Transformationen wie die von Garvins Acronym-Plugin sind wiederum ohne weiteres Cachebar, da hier der Status - es hat sich was bei den Akronymen geändert oder eben nicht - bekannt ist.
In einem zweiten Schritt sollte also darüber nachgedacht werden, ob es sinnvoll ist, Zwischenergebnisse zu cachen. Das es hier für die Effektivität auf die Reihenfolge ankommt, und cachende Prozessoren vor den nicht cachenden Prozessoren laufen ist dem geneigten Leser inzwischen hoffentlich selbstverständlich.
Posted Nov 17, 2004
Tagged as: Caching, s9y, Scalability
<<< Page 1 of 1 >>>