Webprojekte: Caching

Aus beruflichen Gründen (seto-social) habe ich mich in den letzten Monaten immer mal wieder damit befasst wie man bei stark interaktiven Webprojekten am günstigsten Cachen, also bereits generierte Daten zwischenspeichern, könnte.

Die Standardversion ist wohl bei den meisten Frameworks bereits generierte Teile einer Seite oder gar komplette Seiten als statischen Content auf der Festplatte zwischenzulagern und so PHP-Ausführungs-Aufwand drastisch zu verringern.
Bei relativ statischen Seiten funktioniert dies auch sehr schön, ein Blog kann z.B. den kompletten Artikel als HTML ablegen und nur bei Änderungen oder Kommentaren aktualisieren.
Doch was macht man bei Dingen die sich permanent aktualisieren oder gar für jeden Nutzer anders aussehen?

Bei diesem Problem hilft es dann auch nichts dass z.B. Symfony für nahezu jede Caching-Engine (sei es Memcached, XCache, APC oder EAccelerator) ein eigene Klasse mitbringt, die alle von sfCache abgeleitet sind und alle relativ leicht austauschbar die selben Funktionen bieten.
Schlimmer noch: Caching-Engines zu verwenden die die komplette Seite über mehrere Requests hinweg aus dem RAM holt ist natürlich extrem schnell... aber alles andere als RAM-sparend.

Günstiger ist da schon die Klasse sfFunctionCache, die darauf ausgelegt ist einzelne Funktionsaufrufe zu Speichern und so auf einer viel kleineren Ebene arbeitet. Doch auch hier ist es wie so oft: Die Idee ist gut, aber die Umsetzung nicht so genial.
sfFunctionCache erwartet als Identifikator jeweils einen String (normalerweise also z.B. den Funktionsnamen) und speichert dann Beliebigen Text in eine Datei mit diesem Namen.

Die erste Variante dieser Vorgehensweise war den String für den Identifikator zu erweitern... Ein MD5-Hash der Parameter macht es z.B. möglich Funktionen auch abhängig von ihrem Eingangswert zu speichern.
Leider sind nun Dateizugriffe nicht gerade das schnellste was man sich so vorstellen kann. Vor allem wenn man versucht auf möglichst kleiner Ebene zu Cachen und so enorme Mengen an Aufrufen hat und dafür nur minimale Datenmengen Speichert.
In extremen Fällen kann dies z.B. dazu führen dass tausende Dateien angelegt werden, alle mit einem serialisiertem Boolean-Wert als einzigem Inhalt. Diese Dateien werden dann bei jedem Zugriff wieder angefasst und treiben die IO-Last des Servers schneller in die Höhe als man wissen will.

Natürlich könnte man hier auch wieder auf alternative Caching-Engines umsteigen, dann ist jedoch die Symfony-Klasse sfFunctionCache wieder ziemlich sinnlos, da diese wieder nur von sfFileCache abgeleitet wurde statt irgendwie von einer generischen Klasse.
Auch könnte man die Caching-Engine direkt ansprechen, es ist ja nicht direkt so als wären die APIs für diese Systeme extrem komplex.

In unserem Fall aber haben wir uns für einen anderen Ansatz entschieden. Anstelle eine weitere Engine zu installieren, die Daten verwaltet, fanden wir es sinnvoller eine bereits installierte Software zu verwenden, die ebenfalls darauf optimiert ist kleine Datenhäppchen zu verwalten, zu suchen und diese möglichst schnell zugreifbar zu machen.
Wir verwendeten MySQL!

Um also unsere Funktionen zu beschleunigen, setzten wir einfach für jeden Funktionsaufruf eine Zeile in eine MySQL-Tabelle, die nur aus dem Primärschlüssel (ein String der aus dem Funktionsnamen und dem Parameterhash besteht), dem Ablaufzeitpunkt und einem Content-Feld mit serialisierten Daten besteht.
Weil wir sehr wenige Daten speichern, diese aber extrem schnell sein sollten, verwenden wir Memory als Tabellentyp.

Um nun eine Funktion aufzurufen, brauchen wir nur noch nachsehen ob diese bereits im Cache liegt (eine Suche via PK, sollte schnell gehen, den Zeitpunkt ignorieren wir hier mal) und wenn dem der Fall ist, so unserialisieren wir die Daten und geben Sie zurück.
Wenn dem nicht der Fall ist, so führen wir die gewünschte Funktion aus (via call_user_func) und prüfen ob die Daten länger sind als die maximale Stringlänge der Datenbank (wir wollen ja weder defekte Daten speichern, noch wegen 1-2 Aufrufen am Tag massiv lange Varchars produzieren).
Wenn die serialisierten Daten also in die Datenbank passen, fügen wir sie ein und geben sie gleichzeitig als Rückgabewert zurück.

Dies ermöglicht es uns beliebige Funktionen relativ einfach zu den gespeicherten hinzuzufügen, indem wir im entsprechenden Objekt die Funktion umbenennen (idealerweise nach einem festem Schema, aus foo() wird also z.B. fooCache()) und in der __Call-Funktion des Objektes beim Aufruf einer nicht vorhandenen Funktion zu prüfen ob statt der gewünschten Funktion vlt. doch eine existiert deren Namen nach unserem Schema verändert wurde...
Wenn wir also feststellen dass jemand von unserem Objekt die Funktion foo() haben möchte und wir nur eine fooCache() haben, so rufen wir unsere Cache-Lib auf und lassen diese die Arbeit machen (im Cache nachschlagen, Ergebnisse bei Bedarf von fooCache holen und ähnliches).

Diese Vorgehensweise ist sicher noch nicht ideal... aber sie beschleunigt manche Dinge schonmal enorm ohne die vielen Nachteile der vorgegebenen Caching-Varianten zu besitzen.
Ich würde mich über Kommentare mit Verbesserungsvorschlägen oder Dingen die euch aufgefallen sind natürlich wie immer freuen. :-)