Webseite mit Varnish beschleunigen

Dynamische Webseiten führen in der Regel bei jedem Aufruf Datenbankabfragen durch und generieren die Seite für jeden Besucher neu. Bei vielen Besuchern ist eine hohe Last die Folge. Noch wichtiger ist dass dabei Zeit verloren geht – Zeit, die unmittelbar in die SEO-Bewertung einfließt und ungeduldige Besucher zum Absprung veranlasst. Dagegen gibt es viele Mittel: Schlanke Themes, wenig Plugins – und Caching.

Die Idee ist einfach: Ein Cache liefert gespeicherte Seiten auf Anfragen (Requests) anstelle des Webservers aus, der diese im Falle dynamischer Seiten erst generieren muss. Bei Änderungen wird der Cache darüber informiert und baut seinen Speicher neu auf. Ein solcher Cache ist beispielsweise Varnish, der als Reverse Proxy vor dem eigentlichen Webserver den Request bearbeitet. In der Regel ist dem Varnish selbst wieder ein Webserver vorgeschaltet, der die HTTP-Verbindung des Clients terminiert:

Einbindung von Varnish als Reverse Proxy vor dem eigentlichen Webserver
Einbindung von Varnish als Reverse Proxy vor dem eigentlichen Webserver

Dieses Setup ist nötig, weil Varnish nur auf Port 80 binden kann. Spätestens wenn man auch SSL-verschlüsselten Zugriff erlauben möchte, ist der Einsatz eines Webservers vor dem Varnish nicht zu vermeiden. Die Entwickler von Varnish haben SSL-Unterstützung absichtlich nicht implementiert.

Funktionsweise von Varnish

Varnish funktioniert wie endlicher Automat. Ein Request befindet sich immer in einem Zustand. Dies ist anschaulich über ein Diagramm aus der Varnish Einführung nachvollziehbar. Jeder Zustand endet mit dem Sprung in einen anderen Zustand. In der Konfiguration wird dies durch die Funktion return() abgebildet. Varnish ist eigentlich in den Repositories aller üblichen Linux-Distributionen verfügbar. Unter Debian gibt es in /etc/varnish/default.vcl eine solide Grundkonfiguration.

In den Cache kommen alle Objekte, die keinen Cookie- oder Authorization-Header haben. Dies macht in den meisten Fällen Sinn, weil diese Header auf personalisierte Inhalte hinweisen, die nicht zwischengespeichert werden sollen. Eine Änderung ist an dieser Stelle daher nicht nötig, um einen spürbaren Leistungszuwachs zu erreichen

Löschen zwischengespeicherter Inhalte

Bei Änderungen auf der Seite empfiehlt es sich, den Cache zu löschen (purgen). Zwar muss der Cache dann neu aufgebaut werden, Besucher sehen dann allerdings sofort die Änderungen. Damit nicht jeder Besucher den Cache löschen kann, wird dies über eine zusätzliche Konfiguration z.B. auf Localhost begrenzt:


acl purge {
"localhost";
}

sub vcl_recv {
if (req.request == "PURGE") {
if (client.ip !~ purge) {
error 405 "Not allowed";
}
return (lookup);
}
}

sub vcl_hit {
if (req.request == "PURGE") {
purge;
error 200 "Purged";
}
}

sub vcl_miss {
if (req.request == "PURGE") {
purge;
error 200 "Purged";
}
}

Quelle: https://www.varnish-cache.org/docs/3.0/tutorial/purging.html

Für viele Content Management Systeme gibt es Plugins, die bei Änderungen an Inhalten einen Purge durchführen. Für meine WordPress-Installation beispielsweise verwende ich das einfach gehaltene Varnish HTTP Purge Plugin.

Fazit

Beim Einsatz von Caching ist Vorsicht angebracht. „Lieber einmal zu wenig als einmal zu viel“ ist eine gute Richtschnur. Beim Einsatz von Varnish ist die mitgelieferte Grundkonfiguration ein guter Anfang. Die verwendete Varnish Configuration Language ist allerdings nicht sehr intuitiv. Daher sollte man die Grundkonfiguration verstanden haben, bevor man eigene Änderungen einpflegt.

Ersten Kommentar schreiben

Antworten

Deine E-Mail-Adresse wird nicht veröffentlicht.


*