Webserver-Tuning mit varnish

Diesen Beitrag schrieb ich 13 Jahre und 1 Monat zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 1 Minute

Mein Webserver war lahm. Ihr kennt das. Nicht unresponsive, aber gerade so, dass es nervte. Und: der apache2 futterte so langsam auch richtig Ressourcen. Nicht im roten Bereich und auch nicht so, dass das Netzteil gequalmt hätte, aber gerade so, dass es nervte. Und meine Lösung hieß varnish, und die stelle ich euch hier in ultra-kurzer Konfiguration vor – es ist wirklich keine Raketenwissenschaft!

varnish installieren

$ apt-cache search varnish
varnish - a state-of-the-art, high-performance HTTP accelerator
$ sudo apt-get install varnish

apache2 für das Zusammenspiel mit varnish konfigurieren

Den apache2 auf Port 8000 und ausschließlich localhost lauschen zu lassen ist eine Möglichkeit; natürlich führen hier, wie immer, viele Wege nach Rom…

## file: "/etc/apache2/apache2.conf"
NameVirtualHost *:8000
Listen 127.0.0.1:8000

varnish konfigurieren

In meinem Setup muss varnish auf Port 80 lauschen und dort Anfragen entgegennehmen:

## file: "/etc/default/varnish"
NFILES=131072
INSTANCE=$(uname -n)
DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G"

Weitergabe konfigurieren

Abschließend wird konfiguriert, dass alles, was nicht von varnish (Port 80) selbst beantwortet werden kann, an apache2 (Port 8000) durchgereicht werden muss:

## file: "/etc/varnish/default.vcl"
backend default {
  .host = "127.0.0.1";
  .port = "8000";
}
sub vcl_deliver {
  remove resp.http.X-Varnish;
  remove resp.http.Via;
  remove resp.http.Age;
  remove resp.http.X-Powered-By;
}

Mittels ab, dem apache bench, kann man prima schauen, wie die aktuellen Werte so sind; ich habe den roten Aufruf zum ersten Mal vor Installation und Konfiguration gestartet. Nach Inbetriebnahme von varnish habe ich den Aufruf erneut gestartet.

$ ab -n 25 https://www.unixe.de/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
[...]
Concurrency Level:      1 (1)
Time taken for tests:   29.438 (16.374) seconds
Complete requests:      25 (25)
Failed requests:        0 (0)
Write errors:           0 (0)
Total transferred:      1312025 (1314051) bytes 
HTML transferred:       1305525 (1305525) bytes
Requests per second:    0.85 (1.53) [#/sec] (mean)
Time per request:       1177.518 (654.974) [ms] (mean)
Time per request:       1177.518 (654.974) [ms] (mean, across all concurrent requests)
Transfer rate:          43.52 (78.37) [Kbytes/sec] received

Connection Times (ms)
                  min        mean[+/-sd]             median         max
Connect:        56 (63)    71 (103)  16.8 (169.6)     68 (65)     147 (915)
Processing:    993 (415) 1106 (552)  71.4 (566.1)   1104 (421)    1273 (3259)
Waiting:       282 (70)   358 (134)  51.2 (279.9)    355 (71)     527 (1467)
Total:        1060 (479) 1177 (655)  80.0 (735.2)   1169 (487)    1379 (4174)

Was in meinem Setup zu beachten ist: jegliche Anfrage, die fortan an den Webserver gestellt wird, kommt selbstredend von 127.0.0.1! Mir ist das egal, da ich aufgrund meiner eigenen Datenschutz-Policy ohnehin seit Monaten auf das Festhalten jeglicher IPs verzichte. Für so manchen Webseiten-Betreiber könnte das jedoch durchaus ein Problem darstellen, allerdings ein lösbares. Konsultiert also (wie immer) die manpages und weitere Dokumentation, und ihr werdet feststellen, dass dieses kleine Paket eine Fülle an Möglichkeiten bietet.

Alle Bilder dieser Seite: © Marianne Spiller – Alle Rechte vorbehalten
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten

Eure Gedanken zu „Webserver-Tuning mit varnish“

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd. Deshalb behalte ich mir auch vor, die richtig blöden kurzerhand wieder zu löschen. Die Kommentarfunktion ist über GitHub realisiert, weshalb ihr euch zunächst dort einloggen und „utterances“ bestätigen müsst. Die Kommentare selbst werden im Issue-Tracker und mit dem Label „✨💬✨ comment“ erfasst – jeder Blogartikel ist ein eigenes Issue. Über GitHub könnt ihr eure Kommentare somit jederzeit bearbeiten oder löschen.