©Sascha Burkard, 123rf.com

Wenn über 50 000 gleichzeitige Besucher Tausende von Bildern anfordern, stoßen Webserver an Grenzen. Wie Admins es schaffen, Übertragungsraten um 150 MBit/s sicherzustellen, zeigt dieser Artikel.

“Apache ist für uns Bloatware.”, klagen Admins großer Webangebote gerne. Für anspruchsvolle Webseiten mit hohem Traffic-Aufkommen taugt der Indianer weniger, er eignet sich als Reverse Proxy nur für kleine bis mittlere Setups. Dann muss Software her, die mit intelligentem Caching den Webserver entlastet.

Linuxer denken da sofort an Squid. Doch auch der hat seine Schwächen, vor allem was das Speichermanagement und die CPU-Belastung angeht. Das Duo Apache-Squid leidet vor allem, wenn große Datenmengen oder viele kleine Dateien ins Spiel kommen. Gut, dass der Markt freier Software einige Alternativen bietet.

Reverse Proxies

Wer schnell viel Daten ausliefern muss, kommt an Caching-Software wie Varnish [1], Nginx [2], Perlbal [3] oder Memcached [4] kaum vorbei. Auch Yahoo sitzt mit am Tisch [5], seit der Suchmaschinenriese seinen Traffic Server unter eine Open-Source-Lizenz stellte und dem Apache Projekt übereignete [6]. Der Yahoo Traffic Server arbeitet seit acht Jahren bei Yahoo und soll im Netzwerk des Herstellers die Auslieferung von 30 Milliarden Web-Objekte und 400 TByte Daten täglich erheblich beschleunigen. Auch das Buzzwort Cloud fehlt nicht: Selbstverständlich eignet sich laut Yahoo die Software ideal, um Web-2.0-Anwendungen jeder Art zu beschleunigen.

Perlbal, Memcached, Nginx

Perlbal und Memcached stammen aus dem Hause Danga [7] und dienten ursprünglich für deren eigenes Internet -Portal Live Journal [8]. Während der Cacheserver Memcached ein verteiltes Speichermanagement verwendet, um aufwändige Datenbankabfragen über mehrere Systeme zu cachen, dient Perlbal als waschechter Webserver und Reverse Proxy. Besonders interessant macht ihn die Fähigkeit, dass Admins beliebige Konfigurationsänderungen on the Fly, ohne Neustart erledigen können, sowie das ausführliche, maschinenlesbare Management-Interface mit Statistiken und Monitoring.

Auf dem Webserver und Reverse Proxy Nginx (ausgesprochen “Engine X”) laufen laut der Webseite des Projekts 2007 schon ein Fünftel aller russischen Webseiten, dazu gesellen sich jeweils knapp zweieinhalb Millionen Webseiten in China und den USA. Die Tendenz ist steigend, vor allem im Bereich der Highend-Server kann Nginx punkten. Der modular aufgebaute Proxy soll außerordentlich leistungsfähig und flexibel konfigurierbar sein und wurde eigens für die russische Suchmaschine Rambler [9] entwickelt, mittlerweile setzen auch Seiten wie WordPress darauf.

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.

Messwerte und Konfiguration

Dass die Admins von Spin trotzdem Varnish einsetzen, liegt an den Messwerten. Der Lack-Proxy schneidet in fast allen Tests deutlich besser ab als Squid und erreicht die erforderliche Bandbreite locker. Den fehlenden persistenten Cache verschmerzen die Spinler, weil Varnish schon eine Stunde nach einem Ausfall wieder 70 Prozent Trefferquote meldet. Abbildung 3 zeigt das in dem Einbruch gegen 14:30 Uhr.

Was Hitrates und Speichernutzung angeht, zeigen Monitoringtools wie Munin auf Dauer ohnehin nur mehr Diagramme in Blockform ohne große Abweichungen (Abbildung 4). Den Varnish-Maschinen reichen 48 GByte RAM, auf jeder Maschine genehmigen sich drei Proxy-Prozesse je gut 20 GByte Speicher, eine Obergrenze dafür gibt es nicht. Squid dagegen war trotz langer Versuche nicht dazu zu bewegen, den verfügbaren Speicher komplett zu nutzen.

Abbildung 4: Die Varnish-Prozesse nutzen die 48 GByte RAM komplett und dauerhaft aus, auch wenn, wie in KW 13, zusätzliche Ressourcen frei werden.

Detaillierte Messwerte eines Vergleichs zwischen Varnish und Squid finden sich auf [11], wo Bryan Migliorisi in umfangreichen Tests für Varnish doppelt so gute Ergebnisse feststellt wie für Squid. Der Autor räumt zwar selbst ein, damit viel Stoff für Flamewars zu liefern, konstatiert aber auch in Teil 2 seiner Untersuchungen, dass Squid unter hoher Last schlechter abschneidet als Varnish. Das bestätigen auch die Erfahrungen bei Spin.

Varnish ist schnell für ein Setup wie in Abbildung 1 konfiguriert. Die Einstellungen erfolgen in drei Dateien, mit einer eigenen Skriptsprache in »/etc/varnish/default.vcl« (Listing 1), Parameterpaaren in »/etc/default/varnish« (in Listing 2 bereits mit Optimierungen für viele kleine Dateien versehen) und in »/etc/sysctl.conf«:

net.core.somaxconn=2048
net.core.netdev_max_backlog=300
net.netfilter.nf_conntrack_max=131072

01 backend squid1 {
02 .host = "10.10.42.5";
03 .port = "80";
04 }
05 
06 backend squid2 {
07 .host = "10.10.42.6";
08 .port = "80";
09 }
10 
11 director default round-robin {
12 {.backend = squid1; }
13 {.backend = squid2; }
14 }
15 
16 sub vcl_recv {
17 if (req.http.Cookie) {
18 unset req.http.Cookie;
19 }
20 set req.backend = default;
21 }

01 NFILES=131072
02 MEMLOCK=82000
03 INSTANCE=$(uname -n)
04 
05 VARNISH_VCL_CONF=/etc/varnish/default.vcl
06 VARNISH_LISTEN_ADDRESS=
07 VARNISH_LISTEN_PORT=80
08 VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
09 VARNISH_ADMIN_LISTEN_PORT=6082
10 VARNISH_MIN_THREADS=1
11 VARNISH_MAX_THREADS=1000
12 VARNISH_THREAD_TIMEOUT=120
13 VARNISH_STORAGE_FILE=/var/lib/varnish/$INSTANCE/varnish_storage.bin
14 VARNISH_STORAGE_SIZE=250G
15 VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"
16 VARNISH_TTL=120
17 
18 DAEMON_OPTS=" -a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT}
19 -f ${VARNISH_VCL_CONF}
20 -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT}
21 -t ${VARNISH_TTL} 
22 -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT}
23 -p lru_interval=1800 -h classic,500009 
24 -s ${VARNISH_STORAGE}"

Mehr Details zu den Verbesserungen finden sich auf der Varnish-Webseite [1]. Anstelle des vergleichsweise behäbigen Apache setzen viele Admins auch schlanke Webserver wie den “Tiny/Turbo/Throttling HTTP Server” Thttpd [12]. Den dynamischen Content der Spin-Webseiten (Chat, Flash, Foren,…) erledigen spezialisierte Web-, Cache- und Datenbankserver im Bladecenter nebenan, wo auch die Entwicklungsumgebungen hausen. In den Stoßzeiten machen diese Inhalte gerne weitere 50 MBit/s aus.

Wenig Ausfallzeit

Dank des simplen DNS-Loadbalancing und der Proxy-Kaskade gab es laut Hechtbauer in den letzten Jahren nur wenige Minuten, in denen die Benutzer Verzögerungen merken konnten. “Wir haben zwar häufiger Leistungsprobleme mit diversen Kerneln festgestellt, vor allem, wenn mehr als 100 MBit/s Traffic anfielen.” Aber dann stellen die Admins der Proxy-Kaskade einfach einen weiteren, gemieteten, virtuellen Rechner oder ein zusätzliches Blade zur Seite, passen die DNS-Einträge an und das Problem ist für Spin gelöst.