Blog-Relaunch mit Serendipity
Nach etwa einem Jahr mit einer selbstgebastelten Blogsoftware habe ich mich nun dazu entschlossen, sie durch Serendipity (s9y) zu ersetzen. Dies ist darin begründet, dass ich meine Hauptdesignentscheidung, welche das direkte Ausliefern der Webseiteninhalte ohne PHP-Bremse umfasst, mit meinem jetzigen Wissen geschickter lösen kann. Außerdem war mir der Aufwand einen Blogbeitrag zu erstellen in meinem alten System zu hoch.
Ladezeit
Bei meinem alten System hat ein Cronjob stündlich sämtliche Inhalte in HTML-Dateien gerendert, damit der Webserver nicht erst irgendein Skript anwerfen muss, um die Inhalte zusammenzustellen. In Kombination mit dem gatling-Webserver stand zumindest auf Serverseite einem schnellen Seitenaufbau nichts im Wege. Auch der Ressourcenverbrauch dieses Setups war äußerst gering. Gegen Ende habe ich aber angefangen, dieses Prinzip aufzuweichen. Eine Suchfunktion über sämtliche Microblogeinträge ließ bei jeder Anfrage ein PHP-Skript laufen. Es war egal, ob dabei 100 mal das gleiche gesucht wurde. Immer wurde PHP bemüht, die Informationen zusammenzukratzen.
Varnish
S9y ist ohne PHP nicht lauffähig. Ich setze nun den Webserver nginx ein, da s9y erweiterte URL-Rewrites für den Betrieb benötigt. Der Webserver spricht über FastCGI direkt mit einem ständig laufenden PHP-Prozess um derartige Anfragen rendern lassen zu können. Nginx lauscht lediglich auf einer lokalen Adresse. Vor ihm steht der Cache Varnish, welcher auf Port 80 Anfragen entgegen nimmt, bisher nicht gecachte Inhalte vom nginx bestellt und sie sich dann für eine Stunde merkt. Wenn also nun Fefe aus irgendeinem Grund auf eine meiner Seiten linkt, muss mein Server nicht aufgrund von Überlastung zu Grunde gehen. Varnish hält die Inhalte im Hauptspeicher zum direkten Ausliefern bereit und sämtliche Besucher bekommen die Inhalte schnell ausgeliefert.
Nutzerintraktionen
Dieses Vorgehen bedeutet auch, dass Nutzerinteraktionen, wie z.B. Kommentare, frühestens nach einer Stunde sichtbar sind. Ob sich dieses Setup bewährt, werde ich erst sehen, wenn es ein Stückchen gelaufen ist. In einem nächsten Schritt kann ich einen Cronjob anlegen, welcher nach 55 Minuten den Varnish-Cache leert und sämtliche Seiten bestellt, um den Cache zu erneuern und eine schnelle Auslieferung sicherzustellen. Dies lässt zwar eine konkrete Suchanfrage nach "Bla" trotzdem das PHP arbeiten, allerdings passiert das für gleiche Suchanfragen innerhalb einer Stunde nur einmal. 
Ressourcen
Varnish lasse ich bis zu 256 MB für den Cache nutzen. S9y greift auf SQLite zurück, damit ich mir den ressourcenfressenden MySQL-Server spare. Böse Menschen können den Cache locker voll laufen lassen und ihn zum Flattern bringen. Gegen das können meines Erachtens nur Firewallregeln helfen, die ich einrichte, wenn erste Angriffe aufschlagen. Im Bild sind Varnish, Nginx und der PHP-Prozess samt aktuellem Ressourcenverbrauch zu sehen.
Kommentare
Thomas Heidrich am :
Markus Sowada am :