Varnish Cache Server

Du hast ein paar Euro uebrig im Monat fuer deinen Blog und der laeuft auch ganz nett. Irgendwann denkst du dir dann aber 'Das Ding laed echt ganzschoen lange'. Du optimierst, installierst dir gefuehlte hundert Wordpress-Cache-Optimierungs-Plugins und doch will alles irgendwie nichts so recht helfen, es laed immernoch langsam.

Wir alle wissen, dass langsame Seiten Benutzer vergraulen, also schaust du dich weiter um und dann ist da vielleicht die Loesung.

Varnish.

Ich habe zwar keinen Wordpress-Blog (mehr), sondern einen statischen Blog, der von Pelican generiert wird. Also fertige HTML-Dateien, die nur noch gelesen werden muessen. Man koennte jetzt denken, dass wuerde doch kaum noch etwas bringen, wenn ich den in Varnish werfe, aber weit gefehlt.

Der groesste Vorteil von Varnish ist, dass die Software tatsaechlich als reiner HTTP-Proxy angelegt ist. Er unterstuetzt also weder andere Protokolle noch wird Wert auf die Verwendung als Cache auf Client-Seite gelegt. Alles was Varnish speichert, kann direkt im RAM gelagert werden, die Zugriffszeiten sind also auch entsprechend niedrig und koennen selbst statische Seiten die mit nginx ausgeliefert werden beschleunigen.

Im folgenden kleinen Beispiel habe ich fix den Blog gecrawled - im ersten Lauf auf einem leeren Cache, im zweiten mit gefuelltem Cache. Zu dieser Zeit waren das etwa 50 Seiten.

┌─[izzy][rizzl][○ ][~]
└─▪ time wget --spider --recursive \
        --no-verbose \
        --output-file=wgetlog.txt \
        blog.unikorn.me

real    0m4.828ss
user    0m0.043s
sys     0m0.060s


┌─[izzy][rizzl][○ ][~]
└─▪ time wget --spider --recursive \
        --no-verbose \
        --output-file=wgetlog.txt \
        blog.unikorn.me

real    0m2.579s
user    0m0.043s
sys     0m0.053s

Wow, nur noch etwa die haelfte der Zeit fuer die knapp 50 Seiten. Das sind pro Element nochmal etwa 40ms weniger Ladezeit. Das klingt vielleicht nicht viel, aber wenn man bedenkt, dass beim initialen Aufruf der Seite mehrere Requests gemacht werden und die meisten Browser pro Server die Anzahl der gleichzeitigen Requests auf 6 bis 8 beschraenken, kommt da dann schon einiges an Ladezeit zusammen.

Das ist aber lange nicht alles. Wer will, kann auch definierte Regeln nutzen, um das Verhalten von Varnish zu veraendern. So koennen acht Subroutinen genutzt werden, um zum Beispiel einzugreifen, nachdem ein Request eingegangen ist oder wie ein Hash-Lookup im Cache aussieht.

Wenn man das ganze richtig nutzt, kann man unter anderem die Applikation auf dem Server, die dynamische Seiten generiert, mit Varnish so koppeln, dass gewisse Seiten aus dem Cache gepurged werden oder statische verzeichnisse so lange wie moeglich im Cache gehalten werden. Ausserdem kann man auf die Art des Requests pruefen und z.B. alles andere als GET-Requests bei statischen Inhalten sperren.






Proudly powered by Microsoft IIS, Visual Basic .NET and DHTML. NOT.
Copyright © izzy
License Info