Im Projekt „Fastblog“ aka „Wir machen unseren WordPress Blog schneller“ haben wir nun Varnish installiert/konfiguriert und die Plesk-Konfig so geändert, dass alles zusammen spielt. Das war der schwere Teil. Nun bringen wir WordPress bei mit dem Cache zusammen zu arbeiten und diesem zu verkünden, wenn was geändert wurde.
Diese Aufgabe ist schnell erledigt, man installiert sich das Plugin „Better WP Varnish“. Das wird von bit51 bereit gestellt, die auch sonst viele Tips und Tutorials für WordPress am Start haben. Im WordPress Plugin Directory findet man es auch. Installieren wie jedes Plugin, dann die sparsamen Settings einstellen und fertig. 
Das PlugIn wird nun dafür sorgen, dass WordPress Änderungen an Inhalten an den Varnish meldet. Dieser löscht die entsprechend geänderten Seiten aus seinem Cache und lädt sie beim ersten Request neu vom Apachen. Damit lässt sich eine lange Lebenszeit im Cache realisieren, da geänderte Inhalte ja immer neu generiert werden. Diese Automatik ist auch der Punkt, an dem andere Software scheitert. Dann muss man mit entsprechend kürzerer Speicherzeit leben oder manuell die Inhalte aus dem Cache löschen. Natürlich funktioniert das Ganze nicht so einfach, wie es hier aussieht. Eine Webseite besteht nämlich aus mehr als dem HTML-Quelltext. Unzählige Ressourcen wie Bilder und CSS werden neben der eigentlichen Seite ausgeliefert. Diese werden nicht so einfach mitgelöscht. Bei größeren Änderungen am Inhalt, Theme-Änderungen und Ähnlichem sollte man den ganzen Cache löschen. Der Einsatz von Googles Mod-Pagespeed kann auch einiges gerade rücken. Dazu später mehr.
Ein sonderbares Problem ist entstanden durch den Einsatz von 2 zusätzlichen Server-Diensten vor dem eigentlichen Apachen der PHP ausführt. Ohne weiteres Zutun „sieht“ der Apache und damit PHP eine falsche IP. Die wird in den meisten Fällen die IP vom Server sein, bzw. „localhost“ also „127.0.0.1“. Das kommt daher, dass die ursprüngliche IP des Aufrufers am NGinx ankommt, dieser den Request weiter reicht. Die IP ist also offensichtlich die IP von NGinx. Dieses Problem tritt immer auf. Es gibt dafür die Header-Felder „X-Forward-For“ wo dann die anderen IPs stehen. Der Apache bzw. PHP müsste die IP dort heraus beziehen. Man muss also Piwik und alle anderen Programme die auf die IP des Besuchers zugreifen wollen entsprechend auf die Nutzung hinter einem Reverse-Proxy umstellen. Oder man macht es sich einfach.
Apache hat ein Modul namens „RPAF“. Das dient genau dafür, Probleme dieser Art generell zu lösen. Es extrahiert die richtige IP aus den Headern und gibt sie so weiter. Für jede Software sieht also alles wieder so aus vorher. Installiert man unter Ubuntu geschwind:
apt-get install libapache2-mod-rpaf
oder unter CentOS
yum install mod_rpaf
Auf einem Plesk-System wird sicher schon das Paket „psa-mod_rpaf“ installiert sein. Die Konfig Datei enthält bei mir nur diese Zeilen:
RPAFenable On RPAFsethostname On RPAFproxy_ips 127.0.0.1 176.28.51.63 10.105.26.170 RPAFheader X-Real-IP
Den Teil mit hab ich entfernt, da es sowohl auf Ubuntu- als auch auf CentOS-Systemen zum Problem kam, dass das Modul einfach nicht arbeitet. Der Grund scheint zu sein, die ausgelieferte Konfig enthält einen Fehler. Es wird „ifmodul blablu.so“ geschrieben, der Name des Moduls bzw. der Bibliothek ist aber anders! Daher schlägt das IF immer fehlt und das Modul wirkt nie. Ohne der IF-Zeile wird es Fehler geben, wenn das Modul nicht geladen ist, aber es funktioniert. Ich trug alle IPs des Servers ein, die werden entfernt, die zutreffende anderen IP wird als Aufrufer-IP übergeben. Dann arbeitet Piwik wieder mit den echten IPs und in den Logfiles stehen auch wieder die richtigen Werte.
Nun noch der Versuch, mit Mod-Pagespeed von Google das Caching der Ressourcen zu verbessern. Nicht unbedingt nötig, aber sicher kann man nicht einiges raus holen.
Schreibe einen Kommentar