Skip to content

Warum varnish für normale Webserver nichts bringt

Varnish ist ein extrem schneller caching reverse Proxy, der einem normalen Webserver vorgeschaltet wird. In der Regel beantwortet Varnish dann die Anfragen der Benutzer, entscheidet, ob er aus seinem eigenen Cache liefern kann und den Webserver dahinter nicht mehr fragen muss. Da Varnish den Proxy im Speicher hält, bedient er Anfragen extrem schnell. Was er nicht selbst bedienen kann, z.B. weil die Seiten aktive Inhalte haben oder nicht gecached werden dürfen, gibt er an den dahinter liegenden Webserver weiter. Darüber hinaus überwacht er die Webserver und verteilt Anfragen an mehrere Webserver. Fällt einer der Webserver aus, leitet Varnish dort einfach keine Anfragen mehr hin. Benutzer bekommen davon überhaupt nichts mit. Varnish ist übrigens auch völlig anpassbar über eine eigene Konfigurationssprache. Damit lassen sich extrem tolle Dinge relativ einfach realisieren.

Ich kam irgendwann auf die Idee, auch normale, einzelne Webserver mit einem Varnish auszustatten, um die Auslieferung von Web Inhalten zu beschleunigen. Zunächst klang das für mich bei allen oben genannten Vorteilen wie eine Verbesserung. Zumal der Varnish auf dem gleichen Host lief und über eine iptables Regel eingebunden wurde, d.h. mein Varnish war jederzeit im Betrieb transparent ein- und abschaltbar. Nicht mal die Webserver Konfiguration musste ich ändern.

Als ich mir die Statistiken des Varnish ansah, war dort allerdings kaum ein positiver Effekt zu erkennen. Die Cache Hit Rate war oft unter 1%, so dass sich kein erkennbarer Gewinn daraus erzielen liess. Varnishhist zeigt ein ähnliches Ergebnis, aber etwas schöner als Varnishstat:

Ausgabe von varnishhist: Unter (1) sieht man die Hits, unter (2) die an den Webserver weitergeleiteten Requests. Von links nach rechts erhöht sich die Antwortzeit.

Der Grund dafür ist recht schnell ausgemacht. Sobald Cookies existieren, geht Varnish von einer Session aus und leitet einfach alle Anfragen an den Webserver weiter. Da heute die meisten Websites Content Management Systeme für alles einsetzen, läuft bereits beim ersten Besuch ein Cookie auf und eine Session startet. Damit ist Varnish außen vor.

Varnish handelt an dieser Stelle völlig korrekt, um die Stabilität der Webanwendungen vor die Performance zu stellen.

Bei kleinen Webservern, die verschiedene Websites ausliefern und alle nicht auf Varnish optimiert sind, ergibt der Einsatz von Varnish deshalb (leider) auch keinen Sinn. Man kann mittels der Scriptsprache Varnish beibringen, dass er trotzdem statische Dateien wie Bilder, CSS, etc. cached, der Aufwand lohnt sich aus meiner Erfahrung heraus trotzdem nicht.

Ubuntu Jaunty / 9.04 Performance und die Sache mit dem Atom

Auf einem schlanken, schmalen, stromsparenden Atom 230 Rechner installierte ich kürzlich Ubuntu. Zunächst die 8.10, danach per Upgrade die 9.04. Alles lief soweit zufriedenstellend, aber so richtig glücklich war ich mit der Performance nicht. Ich dachte länger, dass es wohl so sei, wenn man einen Atom230 mit einer 1920x1080er Auflösung beauftragt, denn Hubraum lässt sich nur durch mehr Hubraum ersetzen und man daher auch damit leben müsse. Muss man aber nicht.

Nach einigen Änderungen ist mein Atom-Ubuntu nun deutlich flotter als vorher und die Arbeit macht ebenfalls mehr Spass. Hier die Punkte, an die man als leidgeplagter Performance-Junkie Hand anlegen sollte:

  • Remote Desktop abschalten
  • Pulseaudio durch esound ersetzen
  • Python 2.5 deinstallieren, sofern es nicht mehr benötigt wird (Standard ist sowieso Python 2.6)
  • Xorg beschleunigen (hier habe ich das meiste rausholen können)
  • Prozessortaktung beeinflussen
  • "Swappiness" konfigurieren
Mehr zu den einzelnen Punkten gibt's auf hier.
tweetbackcheck cronjob