Die Xenjo Cache Registry Part II

Der Magnet

Das mod_cml meines Lieblingswebservers lighty ist tot. Es lebe das Modul mod_magnet. Das mod_magnet ist an sich noch nichts neues, für die buckligen Kollegen und interessierte, eine kurze Zusammenfassung:

Über eine Konfiguration des lighty kann bei jedem Request ein Script aufgerufen werden. Dieses Script muss ein LUA-Script sein, weil lighty mit dem mod_magnet auch immer einen LUA-Interpreter zur Verfügung stellt. Die Entscheidung für LUA liegt auf der Hand: LUA ist klein (eigentlich nur eine Bibliothek), sehr schnell und geizt mit der Verschwendung von Ressourcen. Es gibt keinen Lade-Overhead beim Aufruf eines LUA-Scripts wie bei PHP oder anderen Interpretern. Vor der Ausführung wird LUA-Code grundsätzlich nach Byte-Code kompiliert. mod_magnet erkennt jedoch jede Änderung und kompiliert das Script bei Bedarf neu. Zusätzlich zu den Möglichkeiten die LUA bietet (mod_magnet verwendet LUA 5.1), stellt der lighty noch etwas mehr Umgebung (u. a. den Zugriff den Request) und seine eigenen stat()-Routine bereit.

Eigentlich bräuchte man, vereinfacht gesprochen, keine lighty-Module mehr zu entwickeln. Mir fallen auf die Schnelle keine wesentlichen Dinge ein, die man mit LUA nicht abdecken könnte. Und wenn doch (oder wenn man das ganze noch etwas beschleunigen will), schreibt man sich das Benötigte direkt in LUA oder baut sich LUA-Befehl in C... Aber ich bin ohnehin eine echte C-\0#, auch wenn es wirklich nicht so schwer ist.

Das richtig fiese ist, dass so ein LUA-Script den Webserver "blockieren" kann - Lighty 1.4.x ist ein Single-Prozess-Webserver, und eben extrem schnell in der Auslieferung statischer Inhalte - und wenn das statische Ausliefern einer Seite dauert, kann kein anderer Request bearbeitet und ausgeliefert werden. Allerdings kann ich mir vorstellen, dass man hier etwas mit einer Max-worker-Konfiguration drehen könnte. Wenn ich einige Highlights der nächsten Lighty-Generation richtig verstehe, wird das mit dem 1.5.x Branch unproblematischer werden.

Das gefährliche an den neuen Möglichkeiten ist also die falsche Anwendung. Nicht mehr und nicht weniger. Anwendungen gehörten nach wie vor auf das CGI- oder FastCGI-Interface. Nicht zuletzt, weil Software immer Fehler enthalten, und im Falle einer "Katastrophe", killt LUA den Lighty. Das kennt man ja noch aus der Apache-1.3-Zeit mit mod_php - wo Licht ist, kann man das auch ausknipsen.

Nebenbei bemerkt: Es existiert für LUA bereits eine CGI-Schnittstelle - allerdings ist ein FastCGI bislang noch ein Traum der Leute des Kepler-Projekts.

Ich halte fest: mit mod_magnet existiert im Lighty nun ein vollwertiger LUA-Scripting-Host, der die Antwortzeiten bei sinnvoller Anwendung vernachlässigbar belastet. Auf den ersten Blick fehlen sogar im mod_magnet gegenüber mod_cml Funktionalitäten. Die Lighty-Umgebung stellt weder die in mod_cml vorhandenen Teile der memcache-API noch Funktionen wie md5 bereit. Das macht aber nix, wieso auch, wenn das alles - wie oben erwähnt - auch in LUA oder einem in C implementierten LUA-Packet "reingeholt" werden kann!

Memcached-Zugriffe können über die libsocket (ich hab' mehrere LUA-Packages gefunden, die die Funktionalität auch kapseln) und der MD5 kann über die libmd5 reingeholt werden. Es gibt einiges mehr, was für die vorderste Webserver-Front praktisch sein könnte. Da wären z.B. cUrl und svn um nur einige zu nennen.

Bevor das hier aber alles zu perfekt klingt: Es ist leider nicht perfekt. Überhaupt nicht. Zum Thema killen musste ich die Woche so meine richtig traurigen Erfahrungen machen: mod_magnet ist im Moment für meine Memcache-Experimente nur bedingt einsatzfähig. Und der Urheber dafür ist, dass u. a. die libsocket den lighty killt. Keine Sockets, kein Memcached-Zugriff. So einfach ist das. LUA selber arbeitet mit der libsocket ohne Fehler, sodass ich wenigstens außerhalb des Lighty testen konnte.

Die Daten

Dennoch macht es keinen gesteigerten Sinn, sich von verschiedenen Ideen abbringen zu lassen. Die da wären: Ein Konzept für eine Anwendungs-Cache-Registry, bei der sicher nicht die Infrastruktur wie lighty oder memcache das Problem darstellen, sondern die Vermeidung, in die Domaine-Schichten Logik für die Präsentations-Schicht zu hämmern. Dieses Problem ist ein architektonisches. Und mit zunehmenden SOAs wird das richtig gruselig (und ist deswegen nicht mein Thema!).

Um ein Seiten-Caching einer Internet-Anwendung sehr schnell zu machen, müsste die Präsentations-Schicht einen Status über die Daten des Models erhalten.
Angenommen, ich verwende in meiner heilen Welt ein ORM-Framework wie Doctine. Und angenommen, alle Anwendungen greifen nur noch über die ORM-Schicht zu. Dann könnte man die Models mit einfachen Triggern erweitern, die wenigstens ihren Status an die große Tafel werfen. Ganz unten versuche ich nochmal auf die Problematik einzugehen.

Aspekte beim Caching

Layouts können sich ändern. Nehmen wir den Fall, wir hätten eine MVC basierte Anwendung die in der Präsentations-Schicht mit einem Template-View arbeitet.

Wenn sich ein Template auf dem Server geändert hat, kann das die Template-Engine, z. B. Smarty, ermitteln. Dazu muss aber die Template-Engine angeworfen werden. Und wenn ich das bei jedem Request tue, ist mein Caching nur bedingt zu gebrauchen, weil wenigstens ein Teil der View-Schicht meiner Anwendung aufgerufen werden muss. Eine gängige Lösung für dieses Problem ist simpel und effektiv: Mit der Änderung des Templates löscht man gleich die involvierten Cache-Files. Lighty muss in dem Fall nur nachsehen, ob ein Cachefile ausgeliefert werden kann oder nicht. Wenn nicht wird die Anwendung aufgerufen, die eines erstellen kann (das soll der Präsentations-Schicht der Anwendung überlassen bleiben).

Dann schneiden wir mal die Sau auf:

In einer PHP-Anwendung gibt es einen Front-Controller (index.php), der URIs in der Form module=&id=&cid= versteht. Für die URI-Transformationen hält normalerweise mod_rewrite her. Hier implementiere ich das einfach mal in LUA:

-- Der memcached-client benötigt die luasocket,

-- die den lighty aktuell noch richtig abkocht...

-- http://luaforge.net/projects/luamemcached/

require('Memcached')



---

-- @var string  Absoluter Pfad zum Cacheverzeichnis

--  

local cache_path = "/home/jbrunner/egolab/magnet/cache/"



---

-- handle_application() wird aufgerufen, wenn wir unsere 

-- Nice-Url an den Front-Controller übergeben müssen - also 

-- immer dann, wenn kein Cachefile vorhanden ist, oder ein 

-- vorhandenes erneuert werden muss.

-- Die Präsentations-Schicht muss sich nun selber um die 

-- Erstellung des Cache-Files kümmern!

--

handle_application = function()

    local module, id, title = string.match(

        lighty.env['request.uri'], 

        '/(%w+)/(%d+)/(%w+).html'

    )

    if (module and id and title) then

        local uri = string.format('module=%s&id=%d&cid=%s', module, id, title)

        if (lighty.env['uri.query']) then

            uri = uri .. '&' .. lighty.env['uri.query']

        end

        lighty.env['physical.rel-path'] = '/index.php'

        lighty.env['request.uri'] = lighty.env['physical.rel-path']

        lighty.env['physical.path'] = lighty.env['physical.doc-root'] 

            .. lighty.env['physical.rel-path']

        lighty.env['uri.query'] = uri

        return lighty.RESTART_REQUEST

    else

        return nil

    end

end

Mit Hilfe des require läd man unter LUA 5.1 ein Modul oder ein Packet. Der Code ist hier nur drin, weil wir das später noch brauchen. Die Variable cache_path hält das Verzeichnis auf der Platte, in dem später unsere Cache-Files liegen. Interessant wird es erst jetzt:

Die Funktion holt sich die Request-URI aus der lighty-Umgebung, parst sie und baut den Request für den Front-Controller auf, wenn soweit alles konform ist. Ist das nicht so, liefert die Funktion nichts zurück (wer Pascal oder Infochick kennt, kennt nil) - lighty kümmert sich wie gewohnt um den Request und arbeitet ihn ab. Im Erfolgsfall macht lighty mit unserer Version des Requests weiter und wird den Aufruf an einen FastCGI-PHP Prozess weiterleiten. Der Prozess muss sich nun selber um die Erstellung des Cache-Files kümmern (ich denke mal das ist trivial und hat fast jeder schon gesehen: Content erstellen, abspeichern und ausgeben…).

Jetzt wollen wir die erste Cache-Decision treffen: Die Präsentations-Schicht hat nun das Cache-File zu einem Request auf der Platte gespeichert. Da will Lighty nun ran, ohne die Anwendung aufzurufen. Das könnte man wie folgt mit einer zweiten LUA Funktion erledigen:

--- 

-- Einfache Überprüfung, ob das angeforderte File im 

-- Cache verfügbar ist - wenn ja wird der Inhalt zurückgeben.

--

handle_cachefile = function()  

    local cache_file = cache_path 

        .. string.gsub(lighty.env['request.uri'], "/", "_")

    if (lighty.stat(cache_file)) then

        lighty.header["Content-Type"] = "text/html"

        lighty.content = {{filename = cache_file }, ''}

        return 200

    else

        return handle_application()

    end

end

Die Funktion handle_cachefile() baut erst einmal den Namen des Cache-Files auf. Aus /wiki/123/lua.html wird /cachefile-pfad/_wiki_123_lua.html. Der führende Unterstrich im Filename zeigt an, dass ich ein fauler Hund bin.
Jetzt kommt ein Zuckerl (ich befürchte ich werde erschossen, wenn ich weiterhin LUA-Speech verwende, aber Roberto Ierusalimschy ist auch so ein Zuckerl): Wir müssen keinen "langsamen" stat()-Call aus einer LUA-Bibliothek nehmen (LUA ist 100% ANSI-C, bis auf das Packetmanagement ) sondern können den schnellen stat()-Call, den lighty implementiert nehmen. Existiert das Cache-File, geben wir ein LUA-Table mit dem Filename zurück - hängen aber an den Inhalt der Datei noch einen HTML-Kommentar, damit man im Test sofort sieht, wann die Ausgabe aus dem Cache kommt. Jetzt geben wir mittels return 200 den HTTP-Statuscode 200 (OK) zurück und übergeben die Kontrolle wieder an lighty zurück, der die Datei ausliefert.

Schnittstellen...

Schwierig wird es nun, wenn lorindol meinen Wiki-Artikel unter /wiki/123/lua.html korrigiert (weil er das kann). Das Wiki-Modul wird einen Datensatz in einer Datenbank updaten. Die einfache Antwort: "Na, dann löschen wir halt nach dem Speichern das Cache-File" wird nicht reichen, um die aktualisierte Version des Eintrags anzuzeigen. Jedenfalls nicht, wenn wir es mit einem Cluster zu tun haben. Und wir haben es nun mal schnell mit einem Cluster zu tun, wenn wir schnell ausliefern wollen, denn zufällig liegt die alte Version unseres Cache-Files noch auf n-1 Nodes!
Die erste Lösung ist die auch die konservativste: Vor dem Aufruf von handle_cachefile() rufen wir die Funktion handle_memcache() auf. Diese nimmt
den String _wiki_123_lua.html einfach als Schlüssel und fragt am Memcache-Demon an, ob ein Cache-File verwendet werden soll. Diese Info gilt dann im gesamten Cluster. Per default existiert dieser Schlüssel nicht; es soll kein Cache-File ausgeliefert, sonder die Anwendung direkt aufgerufen werden. Wenn der Schlüssel existiert, liefern wir einfach nur das Cache-File aus, in dem wir handle_cachefile() rufen. Wenn der Cluster 70 Nodes hält, würde zwar das Cache-File 70 mal erstellt, aber bei 70 Nodes unter Last passiert das (sag ich jetzt einfach mal so): schnell.

Um das mod_magnet-Script abzuschließen: Die LUA-Funktion könnte dann so aussehen:

---

-- Überprüfung, ob der Cache zum angegebenen Request

-- dirty ist oder überhaupt gecached werden darf.

--

handle_memcache = function() 

    local mc = Memcached.Connect('127.0.0.1')

    local cache_decision = mc:get('cachehit:' .. lighty.env['request.uri'])

    if (cache_decision) then

        -- Request soll gecached werden

        return handle_cachefile()

    else

        -- Request soll entweder nicht gecached werden

        -- oder er soll erneuert werden

        return handle_application()

    end

end



-- Cache-Entscheidungen starten:

--

return handle_memcache()

Wie oben bereits erwähnt, hat das schon etwas krankes, auf n Nodes, n Kopien eines Cache-Files vorzuhalten. Und reden wir nicht davon, dass jedes Cache-File IO kostet. Ein gangbarer Weg wäre, die Cache-Files komplett im Memcached zu speichern. Die Funktion handle_memcache() müsste nur geringfügig verändert werden und mit handle_cachefile() kombiniert werden. Die Grenzen in denen sich Memcache bewegt, sind zwar durch das Betriebsystem und die Hardware limitiert, aber eine genug Raum für interessante Überlegung bleiben noch immer (z. B. durch das Aufteilen mehrerer Demons pro Server auf unterschiedlichen Ports).

Zurück zur Anwendung

"Jemand" macht ein manuelles Update auf der Datenbank-Console, oder über ein altes Script, dass noch nicht unsere Domänen-Logik des ORM-Frameworks verwendet, in dem wir einen Datenstatus delegieren können, damit die Präsentations-Schicht weiß, was zu tun ist. Nun bricht das schöne Kartenhaus vollends zusammen, wenn wir den Cache nicht regelmäßig löschen.
Natürlich könnte man in seiner Datenbank Trigger verwenden, die z. B. bei jedem Update entweder Cache-Files löschen oder den weiter oben verwendeten Memcache-Schlüssel löschen. Der Teufel steckt hier einfach im Detail: Eine gecachte Sicht besteht meist aus vielen verschiedenen Daten. Und eine zusätzliche „Welche Cache-Files müssen jetzt gelöscht werden“ – Entscheidung ist definitiv auf der Datenbank-Schicht krank und nicht wartbar.

Wenn man das Problem aber von oben betrachtet, fällt auf, dass ein weiteres, völlig neues Konzept bei der Thematik fehlt: Daten die wir nicht kontrollieren können, werden uns niemals einen Status über Ihre Aktualität liefern. Wir benötigen beim Abholen der Daten eine Expire-Angabe, auf die wir in der Präsentations-Schicht zugreifen können.

Jetzt haben wir es mit dem etablierten Cache-Entscheidungen-Verfahren der Time to live zu tun. Die Seiten eines Mitarbeiter-Portals greifen direkt auf ein oder mehrere LDAP-Server zu. Angenommen, dieses System wird stark frequentiert. Wir können nicht so einfach wissen, wann ein Administrator mit seinem LDAP-Tool in welchen Datensätzen herumfuhrwerkt hat und wann wir deswegen unsere Cache-Files löschen müssen. Das erledigt man dann doch am sinnvollsten mit einem TTL. Mit Memcache zusammen natürlich kein Problem, weil wir die Haltbarkeitsdauer eines unserer Cache-Files beim setzen des Schlüsseln mitgeben können, ohne dass dafür besonders viel zu tun wäre.

Eine wirklich schöne Lösung, das Caching komplett über eine Präsentations-Schicht zu steuern sieht also mau aus. Aber wir haben jedenfalls die Möglichkeit, an eine halbwegs brauchbare Lösung zu kommen, auch wenn die nicht omnipotent wird.

Fortsetzung folgt…