Varnish

Einen besonders guten Ruf unter Insidern genießt Varnish [1]. Der "Lack" (auf englisch: Varnish) für den Webserver nutzt topaktuelle Networking-Features des Linux-Kernels und soll den verfügbaren Arbeitsspeicher effizienter nutzen als alle Konkurrenten. Nachvollziehbar ist das an Setups wie dem der Spin AG aus Regensburg, die eine Proxy-Kaskade (Abbildung 1) mit Varnish, Squid und Apache nutzt, um eine fünf- bis sechsstellige Anzahl an kleinen Dateien in Form von PNG- und Jpg-Grafiken an zehntausende Benutzer übers Web auszuliefern.

Abbildung 1: Zwei Squid-Proxys mit einem persistenten Cache greifen über Apache-Webserver auf das Netapp-SAN zu und beliefern die Varnish-Reverse-Proxys, die die Anfragen der Besucher entgegennehmen

Die Webseite der Chat-Community [10] bietet den (meist jugendlichen Besuchern) umfangreiche Möglichkeiten, Bilder hinauf zu laden, Alben zu betrachten und zu bewerten (Abbildung 2). Eine fünfstellige Anzahl an Besuchern ist bei den Regensburgern zweimal am Tag die Regel, 150 MBit an Daten wollen dann pro Sekunde zu den Browsern der User gelangen.

Abbildung 2: 60 000 Benutzer machen auf den Webservern der Spin AG beim Fotovoting mit.

Den Browser überlisten

Dem Besucher, der zum Beispiel beim Fotovoting aus Abbildung 2 mitmachen will, präsentiert die Webseite lange Listen von Bildern. Dabei bremst zunächst eine Einstellung der meisten Browser die Anzeige aus, die die Anzahl der gleichzeitigen Verbindungen zum Server auf vier bis acht begrenzt. Das bedeutet, der Client kann maximal acht Bilder gleichzeitig laden, egal wie viel freie Bandbreite er zur Verfügung hat. Webserver-Admins tricksen hier die Browser aus, indem sie mehrere Nameservereinträge für die Links zu den Bildern benutzen.

Gerade wenn viele kleine Bilder darzustellen sind, lässt sich so der Seitenaufbau deutlich beschleunigen. Ganz nebenbei springt dabei ein einfaches DNS-Loadbalancing heraus: "Die Nameservereinträge lassen sich auch mal schnell für Testzwecke auf Clouds wie Amazons EC2 umleiten, sodass wir bei Bedarf leicht neue Ressourcen hinzufügen können. Wer dort aber viel Durchsatz kaufen will, muss auch bereit sein, tief in die Tasche zu greifen.", so Andreas Hechtbauer, einer der Admins bei Spin zum Linux-Magazin.

Die vier Proxys (zwei Mal Varnish, zwei Mal Squid) in Abbildung 1 sind so konfiguriert, dass sie auf jeden der acht beteiligten Hostnamen (zum Beispiel »img1.spin.de«) reagieren. Sollte einmal ein dritter Varnish-Proxy notwendig werden, reicht eine simple Korrektur am Nameservereintrag im DNS.

Die Hitrate der Varnishs beziffert Hechtbauer auf "normalerweise um die 98 Prozent. Leider hat Varnish immer noch keinen persistenten (dauerhaften) Cache, sodass wir dafür den Squid dahinter zur Sicherheit noch vorhalten müssen. Dann können wir die Daten schneller ausliefern, wenn doch mal was passiert." Auf dem Squid-Apache-Servern kommen in der Regel ohnehin nur rund zwei Prozent des Traffics an, den Rest fängt Varnish bereits vorher ab (Abbildung 3).

Abbildung 3: Abends gegen 8 Uhr und nachmittags nach der Schule, das sind die Spitzenzeiten der Chat-Community. Hier rauschen knapp 10 MByte/s durch jeden der beiden Varnish-Proxys. die beiden flachen Linien gehören zu den beiden Squid- und Webservern, zu denen fast kein Traffic mehr durchdringt.

Den begehrten persistenten Cache kündigen die Varnish-Entwickler schon lange an und haben ihn in die Entwicklerversion bereits eingebaut. Aber die stabile Version 2.1 lässt auf sich warten. Mindestens so lange braucht es die Squid-Proxys noch.