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.