Experiment: WordPress mit Varnish

Operation „Fastblog“

Man sollte sich nichts vormachen, WordPress ist langsam. Durch diverse PlugIns kann man das ins Unerträgliche steigern. Das ist mir gelungen. Jetzt hat man wie immer im Leben mehrere Optionen.

  1. Man verwendet schnellere Software bzw. macht seine eigene Software schneller
  2. Man behandelt die Symptome, nicht die Krankheit
  3. Man gibt einen Rattenfurz drauf und lässt es wie es ist

Beliebt bei eigener Software wäre 1. Leider ist WordPress ein fertiges Stück Software, wo man als Einzelner nur sehr beschränkt Einfluss auf die Entwicklung nehmen kann, ohne nervige PlugIns ist WordPress auch nicht so sehr langsam. Die Kombination macht es. Auf all die netten Features will ich aber auch nicht verzichten. Option 3 hab ich erfolgreich genutzt. Nun war mal die Option 2 am Plan. Ergebnis ist eine halbwegs arbeitende Konfiguration in einem Sandwich-Stack aus Apache->Varnish->NGinx mit Automatischem PURGE im Varnish und einigen anderen Features. Resultat:

  • Ohne Varnish: Time to first byte: 10s, Seite erscheint nach 15s (Werte die man eh komplett vergessen kann!)
  • Mit Varnish: Time to first byte: 295ms, Seite erscheint nach 1,2s (Externe Inhalte müssen halt geladen werden)

Folgendes tat ich.Plesk unterstützt seit geraumer Zeit eine Reverse-Proxy-Konfiguration aus NGinx als Frontend-Server und Apache als Backend-Server. Das hat wohl den Sinn, dass NGinx viel mehr Requests abarbeiten kann als Apache und an sich als schlanker und moderner gilt. Diese Konfig kann man nun leicht umbiegen, dass zwischen den 2 Webservern noch ein Varnish residiert. Die übliche Konfiguration auf großen Webseiten. An diesem mickrigen Blog würde auch Varnish als Frontend-Server gut funktionieren. Aber ich mag nicht die Automatiken von Plesk beschädigen, was Deployment von Konfigs betrifft. Also eine etwas überdimensionierte Installation. Es gibt nun folgende Aufgaben:

  1. Installation vom Varnish am Server, Konfiguration
  2. Bearbeiten der NGinx-Templates von Plesk 11.5
  3. Varnish-Cache-Purge-Plugins und GeoIP Probleme
  4. Mod-Pagespeed zur weiteren Optimierung

Am Ende der Geschichte steht ein sehr schneller Blog, der solange schnell ist, bis man Inhalte ändert. Dann bekommt evtl. der erste Aufrufer eine langsame Seite, die dann generiert wird und wieder im Cache landet. Ich meine, eine schnelle Seite wird mehr gelesen und von Google höher bewertet. Es wird also potentiell mehr Traffic auf die Seite geleitet und die Seiten erscheinen höher im Google. So die Theorie. Die Praxis beweist genau das. Und zwar bei einem relativ wenig besuchten Blog wie dem hier sehr drastisch:

piwik
Piwik Statistiken

Wow! Die Hütte brennt! Feuer am Dach! Es gibt einen Lila Strich, der zeigt die Zeit auf, die Seiten zur Generierung brauchen. Der fällt am von um die 5 Sekunden auf irgendwas unter einer Sekunde. Gleichzeitig steigt der blaue Strich, die Besucher von irgendwo unten auf einen akzeptablen Wert. Die Seitenansichten, der orange Strich hüpft total hoch. Vorher fast gleich mit dem blauen, nun höher als der blauen. Besucher schauen also nicht nur eine, sondern mehr Seiten pro Besuch an. Klar, wenn die Seite schon ewig lädt, hat man keine Lust, weitere Seiten zu betrachten. Der Zusammenhang von Ladezeit und Besucherzahlen ist klar zu erkennen.


Beitrag veröffentlicht

in

, , ,

von

Schlagwörter:

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert