Varnish (https://www.varnish-cache.org/) ist zu einer der beliebtesten Reverse Proxy Caches für statischen Webcontent geworden und bietet einen sehr hohen Grad an Flexibilität. Die eigene Konfigurationssprache VCL (Varnish Configuration Language) ermöglicht ein großes Spektrum an Konfigurationseinstellungen und besonders die ESI-Unterstützung in Varnish entwickelt sich zu einer immer beliebter werdenden Schnittstelle für Webapplikationen und Webframeworks. Zuletzt stellten die Entwickler des PHP Frameworks Symfony (http://symfony.com/) in Ihren aktuellen Beiträgen und Schulungen zu Symfony 2 die aus dem Framework heraus bedienbare ESI-Unterstützung am Beispielen von Varnish vor.

Gerade auf Grund dieser Beliebtheit und solch flexibler Möglichkeiten, entstehen immer umfangreichere und komplexer werdende Setups, die in expandierenden Umgebungen schnell intransparent werden und bei anwachsender Anzahl paralleler HTTP-Requests dann nicht mehr beherrscht werden. Die Folgen machen sich dann meist beim Anwender mit langen Ladezeiten bemerkbar. Um dem entgegen zu wirken sollten frühzeitig zumindest grundlegende Parameter im Monitoring und Graphing aufgenommen werden. Die in Varnish mitgelieferten Analysewerkzeuge bieten die Grundlage für ein ausgereiftes Monitoring. Ein gutes Bewusstsein über das Cachingverhalten von Varnish und aufbereitete statistische Werte bieten zudem bei wachsenden Anforderungen und stark dynamischen Umgebungen eine Basis schnell und gezielt reagieren zu können. In diesem Artikel werden grundlegende Aspekte zur Analyse sowie zum Monitoring und Graphing von Varnish beschrieben.

Statistische Auswertungen mit varnishstat

Um einen Überblick über den Status und das Cachingverhalten von Varnish zu bekommen ist es möglich mit dem Befehl “varnishstat” Auswertungen über Objekte, Speicher, Backends und weiteren Parametern einzusehen. Doch Vorsicht: Nach einem Neustart des Varnishprozesses sind diese Werte zurückgesetzt und der Cache ist geleert. Wird varnishstat ohne Optionen aufgerufen, erscheinen statistische Werte, die in einer Schleife jede Sekunde aktualisiert werden (Intervall ist mit der Option -w justierbar) .

In den folgenden Abschnitten und im allgemeinen Kontext zu Varnish, wird ein erfolgreich aus dem Varnishcache geliefertes Objekt als “Hit” bezeichnet. Ist eine Anfrage an ein Objekt nicht aus dem Cache bedienbar, so wird das Objekt im Normalfall an das Backend (z.B. Imagewebserver) angefragt und mit einem aus dem Objekt generierten Hashwert im Varnish-Cache abgelegt. Dieser Vorgang wird als “Miss” und das holen des Objektes als “Fetch” bezeichnet (siehe Abb.1).

varnishstat (ohne Optionen)

In diesem Modus (ohne Optionen) befindet sich in der ersten Zeile die Gesamtlaufzeit des Varnishprozesses. Als nächstes gibt die “Hitrate ratio” in 3 Spalten Auskunft über die Zeitspanne der darunter errechneten durchschnittlichen Hitrate, also das Verhältnis von “Hits” und “Misses” (mehr zu Cache hits siehe Abschnitt “Cache hits und misses“). Abhängig von der Laufzeit des varnishstat Prozesses, beziehen sich die Werte auf 10,100 und 1000 Sekunden (vorausgesetzt die jeweilige Laufzeit ist erreicht). Multipliziert mit 100, ergibt der darunter befindliche Wert “Hitrate avg” das prozentuale Verhältnis der aus dem Cache gelieferten Objekte (Hits) im Verhältnis zu den vom Backend angefragten Objekte (Misses). Ein Wert von 0.9100 sagt also aus, dass durchschnittlich 91% aller angefragten Objekte aus dem Cache bezogen werden. Darauf folgen weitere Werte in vier Spalten, die wie folgt zusammengesetzt sind (siehe Abb. 2).

1. Fortlaufend summierter Wert des jeweiligen Wertes nach Start / Neustart des Varnishprozesses.
2. Durchschnitt / Sek. seit letzter Aktualisierung. Der Standard Aktualisierungswert liegt bei 1 Sek. und ist mit der Option -w justierbar.
3. Durchschnitt / Sek. seit Start / Neustart des Varnishprozesses.
4. Beschreibung des Wertes.

Varnishstat bietet eine Vielzahl an Informationen über den Zustand des Prozesses, der Clientverbidungen, der Backends und des Cachingverhaltens.

varnishstat -1

Mit der Option -1 wird die statistische Ausgabe einmalig angestoßen und eignet sich daher für die Lieferung der Werte an externe Monitoring- und Graphingsysteme (z.B. über SNMP). Da die Werte nach jedem Neustart von Varnish zurückgesetzt werden, muss dies entsprechend in der Monitoring-/Graphingkonfiguration berücksichtigt werden. Die mit “varnishstat -1” ausgebenen Werte sind wiederum ähnlich zu varnishstat (ohne Optionen) in vier Spalten ausgegeben, allerdings in einer anderen Konstitution (siehe Abb. 3).

1. Symbolischer Name des Wertes
2. Jeweiliger fortlaufend summierter Wert nach Start / Neustart des Varnishprozesses.
3. Durchschnitt / Sek. seit Start / Neustart des Varnishprozesses.
4. Beschreibung des Wertes.

Cache hits und misses

Zum Basisgraphing gehören in jedem Fall das bereits beschriebene Verhältnis zwischen “Cache hits” und “Cache misses” um die Effektivität des Varnishcaches bewerten zu können. “Cache hits for pass” beschreibt die Anzahl der nicht cachebaren Objekte z.B. wenn der Set-Cookie header eines Objektes gesetzt ist und fügt den Object Hash in der Cachetabelle hinzu. So kann Varnish dieses Objekt bei einem erneuten Cachelookup identifizieren und den Request sofort an das Backend weiterleiten. Um die Anzahl der Objekte “Cache hits for pass” zu reduzieren und ein effektiveres Caching zu erreichen, überprüfen Sie, ob ggf. Anfragen mit unnötigen Cookies durchgereicht werden. Diese können wie folgt in der VCL-Konfiguration entfernt werden um das Objekt cachen zu können:

# Entferne Cookie nach dem Client Request

sub vcl_recv {

unset req.http.cookie;

}

# Entferne Cookie nach dem Backend Request

ub vcl_fetch {

unset beresp.http.set-cookie;

}

Abgelaufene Objekte

Wenn ein Objekt auf Grund eines abgelaufenen “Expired header” nicht mehr gültig ist, wird dieses Objekt wie erwünscht sauber aus dem Cache entfernt und bei der nächsten Clientanfrage neu vom Backend geholt. Der Zähler des Wertes n_expired wird in diesem Fall pro Objekt mit 1 addiert. Besonderer Aufmerksamkeit sollte dem Wert “LRU nuked Objects” (n_lru_nuked) gewidmet werden, da es sich hierbei um die Anzahl der Objekte handelt, die auf Grund mangelnder Speicherkapazität aus dem Varnishcache gelöscht werden mussten. Die Gesamtanzahl der Objekte im Cache kann zudem mit “n_sess_mem” betrachtet werden.

Zustand der Backends

Der Zustand der Backends sollte mindestens auf Basis der Backendfehler (backend_fail ) im Monitoring aufgenommen werden. Dieser Wert sollte im Idealfall 0 betragen. Folgend ein Beispiel aus der VCL-Konfiguration zur Zustandsbewertung von Backends:

backend be01 {

.host = “my.backend.net”;

.probe = {

.url = “/probe.html”;

.timeout = 60 ms;

.interval = 1s;

.window = 10;

.threshold = 8;

}

}

In dieser Einstellung wird das Backend be01 an Hand der URL “http://my.backend.net/probe.html” jede Sekunde mit einer HTTP-Anfrage getestet. Varnish erwartet diese Anfrage innerhalb von 60 ms beendet zu haben und in einem Fenster von 10 Testabfragen 8 erfolgreich abgeschlossen zu haben. Schlägt dies fehl, wird der Wert backend_fail um 1 erhöht. Eine detailliertere Analyse der Backends kann in der Varnish CLI (varnishadm) mit dem Befehl “debug.health” vorgenommen werden.

Threads

Für Performanceanalysen und  einer optimalen Ressourcenauslastung sollte das Verhalten der Threads aufgenommen werden. Neben der Anzahl neu erstellter und laufender Threads (n_wrk_create und n_wrk), die abhängig von der Hardware und der Anzahl paralleler Zugriffe konfiguriert werden sollten, geben die Werte “worker threads not created” (n_wrk_failed) und “N worker threads limited” (n_wrk_max) Informationen über Engpässe oder Fehlkonfigurationen. Sollte eine überarbeitete Konfiguration der Threadpools ein Ansteigen dieser beiden Werte nicht beeinflussen, müssen Hardwaregruppen (i.B. CPU und RAM) in Betracht gezogen und ggf. erweitert werden.

Logfileanalyse

Mit “varnishlog” steht auf der Kommandozeile ein Tool zur Verfügung, mit dem eine sehr granulare Sicht auf die Kommunikation zwischen Client, Cache und Backend möglich ist. Die mit b (Backend) oder c (Client) gekennzeichneten Logeinträge geben Aufschluss über HTTP-Header, internes Varnish Routing und über den Zustand von Backends und Zugriffe aus der Varnish-Kommandozeileneingabe (varnishadm). Dabei wird das Logging im Shared Memory vorgehalten, welcher ebenfalls zu statistische Auswertung mit varnishstat sehr effizient genutzt wird. Natürlich kann das Logging ebenfalls in eine Datei umgeleitet werden, was in den häufigsten Fällen allerdings zu einem großen Datenvolumen der Varnish-Logdateien führt.

System Monitoring und Graphing

Abhängig von der Wahl des Varanishstorages (file oder malloc) ist das Speicherverhalten unterschiedlich. Die Option “-s” des Varnishdaemon steuert den jeweiligen Cache Storage Typ und bestimmt die im Speicher reservierte Größe des Caches. Diese umfasst jedoch ausschließlich den Objectcache, was bedeutet, dass Daten zum Sessionhandling darin nicht enthalten sind.

Der in den meisten Fällen verwendete und seit Varnish 3 verfügbare Typ malloc geht von einem ausschließlich im Arbeitsspeicher laufenden Betrieb des Objectcaches aus. Daher sollten in diesem Fall die Auslastung des Arbeitsspeichers sowie Swap unter besonderer Obacht gehalten werden. In Situationen in denen der Festplattenspeicher bewusst als Teil des Cachestorages benutzt wird, sollte der Dateityp “file” ausgewählt werden, da so die Organisation der Objekten zwischen Arbeitsspeicher und der Festplatte von varnish optimal erledigt wird. In diesen Fällen sollte das Augenmerk stark auf die IO-Werte der Festplatte gelegt werden, da es bei übermäßigen Auslagerungen schnell zu schwerwiegenden Performanceengpässen kommen kann.

Fazit

Mit Hilfe der von Varnish mitgelieferten Tools und der Integration der beschriebenen Werte in ein Monitoring- und Graphingsystem, können bereits grundlegende Aussagen über die Verfügbarkeit, das Cachingverhalten und über die Auslastung von Varnish getroffen werden. Neben den beschriebenen Werkzeugen, sollten natürlich auch weitere Systemparameter wie z.B. die Anzahl der Verbindungen und der Netzwerktraffic sowohl auf dem Cachingsystem als auch auf den Backends und vorgelagerten Loadbalancern und Firewalls betrachtet werden.

*um hat in einer Vielzahl von Projekten Varnish im produktiven Einsatz. Gerne helfen wir bei der Konfiguration oder der Planung und dem Aufbau hocheffektiver Caching-Infrastrukturen für Ihre Webplattform.