Einführung
Hintergrund
-
Drupal * ist eines der beliebtesten kostenlosen Open-Source-Content-Management-Systeme.
Da eine zugrunde liegende Datenbank zum Speichern und Abrufen von Daten wie Inhaltsseiten, Nachrichten, Kommentaren und Blogeinträgen verwendet wird, benötigt Drupal eine beträchtliche Verarbeitungsleistung, um eine einzelne Seite anzuzeigen. Bei jeder Seitenimpression wird der PHP-Interpreter gestartet, alle Drupal-Elemente verarbeitet, auf die Datenbank zugegriffen, um die Informationen abzurufen, das visuelle Layout vorbereitet und der fertige Inhalt für den Benutzer bereitgestellt.
Dieser intensive Prozess macht es schwierig, mit einer wachsenden Anzahl von Personen fertig zu werden, die die Website gleichzeitig betrachten. Da jeder Besucher eine nicht zu vernachlässigende Menge an Verarbeitungsleistung benötigt, können Ihre Serverressourcen schnell zu einem Engpass werden.
Es gibt viele Möglichkeiten, Wachstum zu bewältigen und Leistungsprobleme zu bewältigen, von denen die meisten als Methode der Skalierung angesehen werden können. Die Skalierung in Bezug auf Software wird als die Fähigkeit des Systems angesehen, eine erhöhte Auslastung wie eine erhöhte Anzahl gleichzeitiger Besucher zu berücksichtigen.
-
Varnish * hilft bei der Skalierung auf Software-Ebene, indem zusätzliche Software hinzugefügt wird, die bei Engpässen helfen kann.
Dieser Artikel wurde unter * Ubuntu 14.04 * getestet, sollte aber unter * Debian 7 * mit geringfügigen Pfadänderungen funktionieren. Es kann auch auf anderen Distributionen mit geringfügigen Änderungen funktionieren.
Lack Cache
-
Varnish * ist ein Cache, dh, er speichert und merkt sich, was eine Webanwendung dem Benutzer beim ersten Zugriff auf den Inhalt bietet. Dann kann derselbe Inhalt * erneut * für nachfolgende Anforderungen bereitgestellt werden, ohne die Webanwendung erneut zu fragen.
Es kann verwendet werden, um statische Inhalte wie Bilder, Skripte oder Stylesheets bereitzustellen, da Varnish unglaublich schnell ist und den Datenverkehr viel besser bewältigt als * Apache *. Es kann auch verwendet werden, um quasi-statischen Inhalt zwischenzuspeichern. Dies sind Inhalte, die dynamisch von der Anwendung generiert werden (unter Verwendung der Datenbank und mit einem erheblichen Zeitaufwand für die Vorbereitung), die jedoch für einen bestimmten Zeitraum unverändert bleiben, sodass die Inhalte für das Caching geeignet sind.
Wenn beispielsweise ein Artikel auf der Website veröffentlicht wird, wird er selten aktualisiert. Es ist dann völlig unnötig, alle verarbeitenden Teile von Drupal in Anspruch zu nehmen, um bei jeder Anforderung denselben Artikel zu berechnen und anzuzeigen. Für Varnish ist es vollkommen in Ordnung, sich daran zu erinnern, die gleiche Seite erneut zu bedienen, ohne Drupal überhaupt zu kontaktieren. Auf diese Weise kann Varnish den gleichen Inhalt problemlos für 10, 100 oder sogar 1000 Personen gleichzeitig bereitstellen - da das Bereitstellen einer zwischengespeicherten Seite nur sehr wenig Verarbeitungsleistung erfordert.
In den meisten Szenarien macht die Verwendung von * Varnish * fast jede Website unglaublich schneller. Dies erleichtert auch die Bewältigung plötzlicher Interessensschübe (z. B. wenn ein sehr beliebter Artikel veröffentlicht wird). All dies führt zu glücklicheren Besuchern, deren Inhalte schneller und zuverlässiger geliefert werden.
Schritt 1 - Apache neu konfigurieren
Standardmäßig überwacht * Apache * Port 80. Auf diese Weise kann Apache Webanforderungen wie eine Browser-URL-Anforderung für * http: //example.com* verarbeiten. Um * Varnish * verwenden zu können, muss es in der Lage sein, diese Anforderungen zu verarbeiten. Zuerst müssen wir Apache anweisen, keine Anfragen mehr auf Port 80 zu bearbeiten.
Ändern der Port-Apache-Listen
Der Port, auf dem * Apache * standardmäßig lauscht, wird in einer Datei namens * Debian * und * Ubuntu * festgelegt, die sich in + / etc / apache2 + befindet.
Bearbeiten Sie die Datei:
sudo nano /etc/apache2/ports.confDaraufhin wird ein * nano * -Texteditor ausgeführt, der den Standardinhalt dieser Datei anzeigt. Dieser sollte etwa wie folgt aussehen. Aktualisieren Sie das + NameVirtualHost + und die Zeilen, um Port * 81 * zu verwenden:
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz
NameVirtualHost *:
Listen
<IfModule mod_ssl.c>
# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
Listen 443
</IfModule>Speichern Sie die Datei, indem Sie * STRG + x *, dann * y * und dann * Eingabe * drücken.
Ändern des Ports für den virtuellen Host
Standardmäßig ist für eine neue * Apache * -Installation ein virtueller Host in einer Konfigurationsdatei in + / etc / apache2 / sites-enabled / 000-default + angegeben. Wenn Sie mehr als einen virtuellen Host konfiguriert haben, müssen Sie * alle * ändern.
Geben Sie zum Ändern der Konfiguration des virtuellen Apache-Standardhosts Folgendes ein:
sudo nano /etc/apache2/sites-enabled/000-default.confDer Inhalt der Datei beginnt mit folgenden Zeilen:
<VirtualHost *:80>
ServerAdmin webmaster@localhostWie zuvor müssen wir die Zahl von * 80 * auf * 81 * ändern:
<VirtualHost *:>
ServerAdmin webmaster@localhostSpeichern Sie die Datei mit * CTRL-x *, gefolgt von * y * und * Enter *.
Apache-Konfiguration neu laden
Nach diesen Änderungen muss die Apache-Konfiguration neu geladen werden:
sudo service apache2 reloadJetzt akzeptiert Apache eingehende Anfragen auf dem neuen Port * 81 * und nicht mehr auf * 80 * wie zuvor.
Wir können dies bestätigen, indem wir unsere Website im Browser öffnen. Sie kann möglicherweise nicht ohne Angabe des Ports geöffnet werden (z. B. * http: //example.com*), wird jedoch nach dem Hinzufügen des neuen Ports zur Adresse (z. B. * http: /) korrekt angezeigt. /example.com:81*).
Jetzt können wir * Varnish * installieren und konfigurieren, um die Site schneller zu machen.
Schritt 2 - Lack einbauen
Sowohl Debian als auch Ubuntu haben Systempakete mit * Varnish *, aber wir empfehlen die Verwendung von vorgefertigten Paketen, die von den Autoren von Varnish erstellt wurden. Dadurch wird sichergestellt, dass Varnish auf dem neuesten Stand ist, was für die Systempakete nicht der Fall ist.
Stellen Sie zunächst sicher, dass das Paket * apt-transport-https * installiert ist, damit das System Pakete über eine sichere Verbindung installieren kann:
sudo apt-get install apt-transport-httpsDies installiert entweder das erforderliche Paket oder teilt uns mit, dass es bereits installiert wurde.
Der öffentliche Schlüssel des Varnish-Paketservers muss installiert werden, um die Authentizität der installierten Pakete zu überprüfen. Wechseln Sie zuerst zu * root *:
sudo suFügen Sie den Schlüssel hinzu:
curl https://repo.varnish-cache.org/ubuntu/GPG-key.txt | apt-key add -Für * Debian *:
echo "deb https://repo.varnish-cache.org/debian/ wheezy varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.listFür * Ubuntu *:
echo "deb https://repo.varnish-cache.org/ubuntu/ trusty varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list-
Sie können jetzt zu Ihrem sudo-Benutzer zurückkehren. *
Aktualisieren Sie Ihr System:
sudo apt-get updateInstallieren Sie den Lack:
sudo apt-get install varnishDadurch wird Varnish installiert und ausgeführt!
Schritt 3 - Lack auf Port 80 abhören
Standardmäßig hört Varnish auf Port * 6081 *. Wir lassen Varnish stattdessen auf Port * 80 * lauschen und nehmen alle eingehenden Anfragen von unseren Webbenutzern entgegen, so wie es * Apache * zuvor getan hat.
Öffnen Sie die Lackkonfigurationsdatei mit:
sudo nano /etc/default/varnishSuchen Sie den nicht kommentierten Abschnitt, der unten angezeigt wird:
. . .
## Alternative 2, Configuration with VCL
#
# Listen on port 6081, administration on localhost:6082, and forward to
# one content server selected by the vcl file, based on the request.
# Use a 256MB memory based cache.
#
DAEMON_OPTS="-a :6081 \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,256m"
. . .Aktualisieren Sie die Zeile, um Port * 80 * zu verwenden (denken Sie daran, auch das + \ + beizubehalten):
. . .
DAEMON_OPTS="-a : \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,256m"
. . .Speichern Sie die Datei mit * CTRL-x * und * y * gefolgt von * Enter *.
Starten Sie * Varnish * neu, damit die Änderungen wirksam werden:
sudo service varnish restartWir sollten Nachrichten wie die folgenden ohne Fehler sehen:
[ ok ] Stopping HTTP accelerator: varnishd.
[ ok ] Starting HTTP accelerator: varnishd.Überprüfen Sie nun Ihre Website im Browser. Anstelle Ihrer Drupal-Site, die zuvor verfügbar war, wird eine weiße Seite mit der Fehlermeldung angezeigt:
Error 503 Backend fetch failed
Backend fetch failed
Guru Meditation:
XID: 131081
Varnish cache serverDas bedeutet, dass Varnish ordnungsgemäß konfiguriert wurde, um eingehende Verbindungen zu akzeptieren, aber noch nicht für unsere Drupal-Site verfügbar ist. In den folgenden Schritten werden Änderungen an der Konfiguration vorgenommen, um die frühere Drupal-Site wieder online zu stellen.
Wie Lack funktioniert
Eine großartige Ressource, um ein solides Verständnis von * Varnish * zu erlangen, ist das offizielle Varnish Book, aber wir werden ein paar grundlegende Fakten darüber behandeln, wie * Lack * wirkt hier.
Sie können auch mit dem nächsten Schritt fortfahren, wenn Sie die Installation jetzt abschließen und später mehr erfahren möchten. Wenn Sie jedoch lernen, wie Lack funktioniert, haben Sie ein besseres Verständnis für die nächsten Schritte.
VCL-Sprache
Die Konfiguration von Varnish ist in einer Sprache verfasst, die * VCL * (Varnish Configuration Language) heißt. Es ist eine einfache Programmiersprache, die von Varnish selbst zu nativem * C * -Code kompiliert wird.
Die Konfiguration besteht aus Methoden, die zusammen mit dem Rest des Konfigurationsinhalts zu unterschiedlichen Zeitpunkten der Verarbeitung eingehender Webanforderungen ausgeführt werden.
Einige Anweisungen werden von Varnish ausgeführt, wenn die Anforderung vom Browser empfangen wird, aber bevor die Anforderung verarbeitet wird. Sie geben an, ob die Anforderung an die tatsächliche Anwendung weitergeleitet oder zwischengespeicherter Inhalt bereitgestellt werden soll. In dieser Anleitung ist es möglich, die eingehende Anfrage zu manipulieren, deren Inhalt zu ändern oder Entscheidungen basierend auf der Anfrage (der URL, dem Dateinamen, den Headern oder den Cookies) zu treffen.
Andere Anweisungen werden ausgeführt, wenn Varnish beschließt, Inhalte aus der tatsächlichen Anwendung (in unserem Fall der Drupal-Website) abzurufen. Diese Anweisungen können verwendet werden, um den von der Anwendung empfangenen Inhalt zu manipulieren.
Weitere Anweisungen werden ausgeführt, wenn Varnish den zwischengespeicherten Inhalt bereitstellt, ohne ihn direkt aus der Anwendung abzurufen.
Mit * VCL * ist es möglich, eine komplexe Logik zu erstellen, die basierend auf vielen Faktoren unterschiedliche Caching-Entscheidungen trifft. Es ist auch möglich, einen sehr einfachen Befehlssatz zu erstellen.
Varnish wird mit einer sinnvollen Standardimplementierung für * alle * Methoden ausgeliefert, die bei Bedarf geändert werden können. Das bedeutet, dass es möglich ist, in der Konfiguration nur * einige * Methoden und auch dann nur * einige * Anweisungen anzugeben, wobei sich der Rest auf die Standardeinstellungen stützt. Das macht es sehr einfach, grundlegende Lackierfähigkeiten zu verwenden, während es möglich ist, sehr komplexe Konfigurationen zu erstellen, wenn Sie benutzerdefinierte Anweisungen hinzufügen.
Was wird zwischengespeichert und was nicht?
Das vielleicht Schwierigste an der Konfiguration von Varnish oder einem anderen Caching-Mechanismus ist die Entscheidung, * wann * und * was * zwischengespeichert werden soll. Die meisten Probleme entstehen durch unsachgemäße Entscheidungen, indem entweder zu viel oder zu wenig zwischengespeichert wird.
Bei einer typischen Drupal-Installation kann dies zu zwei unterschiedlichen Problemszenarien führen.
Die erste Möglichkeit besteht darin, dass nicht genügend Seiten zwischengespeichert werden, wodurch Lack fast unnötig wird. Es beschleunigt die Dinge überhaupt nicht, da die meisten Seiten jedes Mal direkt aus der Drupal-Anwendung abgerufen werden. Dies hilft nicht bei Leistungsproblemen, bringt aber auch nichts zum Erliegen.
Die zweite ist, wenn zu viele Seiten zwischengespeichert werden. In diesem Fall ist es möglicherweise unmöglich, sich überhaupt im Verwaltungsbereich anzumelden. Besucher erhalten möglicherweise alte, ungültige oder sogar vermischte Inhalte, wenn unterschiedliche Inhalte anonymen und angemeldeten Benutzern zur Verfügung gestellt werden. In diesem Szenario ist es möglich, Dinge zu zerbrechen, die ohne Lack einwandfrei funktionierten.
Lassen Sie uns einige allgemeine Faktoren durchgehen, um zu entscheiden, ob * Varnish * Inhalte zwischenspeichern soll oder nicht.
Lack zwischenspeichert alles
In einem Standard-Szenario ist die Grundvoraussetzung, dass Varnish * alles * zwischenspeichert. Das Caching in Varnish ist exclusive, nicht inclusive, was bedeutet, dass alles zwischengespeichert wird, sofern Sie keine andere Regel festlegen.
Anforderungsmethode
Die Anforderungsmethode ist die grundlegende Definition einer Anforderung. Standardmäßig werden die Caches * nur * GET- und HEAD-Anforderungen gelöscht, * niemals * andere wie POST, PUT und DELETE zwischengespeichert. Dadurch wird sichergestellt, dass Anforderungen, die Änderungen an den Daten vornehmen sollen, intakt an die Anwendung weitergeleitet werden, ohne zwischengespeichert zu werden.
Genehmigung
Standardmäßig werden Anforderungen an kennwortgeschützte Seiten überhaupt nicht zwischengespeichert. * Dies gilt nur für Seiten, die mit HTTP Basic Authorization * geschützt sind. Varnish kennt keine anwendungsspezifischen Mechanismen wie Drupal-Anmeldeseiten. Wir müssen unsere eigenen Regeln hinzufügen, um sicherzustellen, dass Anmeldeseiten nicht zwischengespeichert werden.
Überschriften zwischenspeichern
Manchmal geben Webanwendungen ihre eigenen Caching-Informationen in Kopfzeilen zurück. Varnish berücksichtigt diese Header. Wenn also eine Webanwendung wie Drupal Varnish anweist, die Antwort niemals zwischenzuspeichern, geschieht genau dies, es sei denn, wir programmieren ein anderes Verhalten in der * VCL * -Datei. Da Drupal seine eigenen Caching-Informationen sendet, wird dies weiter wichtig.
Kekse
Cookies sind vielleicht der wichtigste und schwierigste Teil, um mit Webanwendungen Caching-Entscheidungen zu treffen.
Wenn Anforderungs- * oder * Antwort-Cookies gesetzt sind, wird die Seite standardmäßig * nicht * zwischengespeichert. Dies ist eine vernünftige Entscheidung, da beispielsweise angemeldete Benutzer durch ein Sitzungscookie identifiziert werden. Wenn Seiten mit Cookies zwischengespeichert würden, würden alle angemeldeten Benutzer denselben Inhalt erhalten und die Anwendung könnte zwischen Benutzern nicht unterscheiden. Es ist jedoch auch eine der Hauptursachen für Probleme, da die Verwendung von Cookies weit verbreitet ist. Häufig sind harmlose Cookies in den Anfragen enthalten, wie z. B. * Google Analytics * -Token, die von der Anwendung überhaupt nicht verwendet werden, deren Inhalt jedoch ebenfalls nicht zwischengespeichert werden kann. Ohne sorgfältige Entscheidungen darüber, welche Cookies das Zwischenspeichern verbieten und welche ignoriert werden sollten, würden wir bei den heutigen Webanwendungen fast kein Zwischenspeichern mehr feststellen, da so viele Cookies im Umlauf sind.
Die meisten Fragmente der Drupal-spezifischen Konfiguration für Varnish befassen sich mit der ordnungsgemäßen Behandlung von Cookies, um unnötige Cookies zu entfernen und das Zwischenspeichern zu ermöglichen, behalten jedoch die erforderlichen Komponenten bei, um beispielsweise die Funktionalität der Verwaltungsseite aufrechtzuerhalten.
Schritt 4 - Konfigurieren von Varnish für Drupal
Mit dem Grundverständnis, wie das Zwischenspeichern mit Varnish funktioniert, können wir Varnish so konfigurieren, dass es mit unserer Drupal-Site funktioniert.
Öffnen Sie die Varnish VCL-Konfigurationsdatei:
sudo nano /etc/varnish/default.vclDer Standardinhalt zeigt an, dass alle Lackmethoden leer sind, was bedeutet, dass die Standardeinstellungen verwendet werden.
Wir können unsere eigenen Konfigurationsanweisungen hinzufügen, um die erforderliche Caching-Richtlinie zu erreichen.
Der erste Block weist Varnish an, wie der Backend-Webserver kontaktiert werden soll, in unserem Fall * Apache * mit einer * Drupal * -Installation. Wir werden den Code so ändern, dass er den Port * 81 * widerspiegelt, den wir zur Konfiguration von * Apache * verwendet haben.
. . .
# Default backend definition. Set this to point to your content server.
backend default {
.host = "127.0.0.1";
.port = "";
}
. . .Suchen Sie nun die leere Platzhaltermethode + vcl_recv +:
. . .
sub vcl_recv {
# Happens before we check if we have this in cache already.
#
# Typically you clean up the request here, removing cookies you don't need,
# rewriting the request, etc.
}
. . .Der Code in dieser Methode wird ausgeführt, bevor * Varnish * unsere * Drupal * -Seite kontaktiert. Hier können wir einige Cookies aus dem Browser entfernen, das Zwischenspeichern (oder nicht) für bestimmte Adressen erzwingen und die erste Entscheidung zum Zwischenspeichern treffen. Wir werden verschiedene Regeln hinzufügen, die Folgendes bewirken:
-
Lassen Sie Varnish bei einem Drupal-Fehler veralteten (alten) Cache-Inhalt bereitstellen. Dadurch wird die Site teilweise verfügbar, auch wenn Drupal nicht reagiert
-
Stellen Sie sicher, dass überhaupt keine Verwaltungsseiten zwischengespeichert werden, sodass Varnish den Cache für bestimmte URLs überspringen muss
-
Stellen Sie sicher, dass statische Dateien - Bilder, Skripte, Stylesheets - zwischengespeichert werden
-
Entfernen Sie alle Cookies außer mehreren Cookies, die Drupal benötigt, um ordnungsgemäß zu funktionieren, einschließlich der Benutzeranmeldefunktionen
Um dies zu erreichen, ersetzen wir den Standardblock durch den folgenden. Mit * # * gekennzeichnete Zeilen sind Kommentare und werden von Varnish nicht berücksichtigt. Sie dienen jedoch dazu, die Konfigurationsdatei verständlicher zu machen. Dieser gesamte Block ist neu und kann wie besehen eingefügt werden:
. . .
sub vcl_recv {
# Return (pass) instructs Varnish not to cache the request
# when the condition is met.
## ADMIN PAGES ##
# Here we filter out all URLs containing Drupal administrative sections
if (req.url ~ "^/status\.php$" ||
req.url ~ "^/update\.php$" ||
req.url ~ "^/admin$" ||
req.url ~ "^/admin/.*$" ||
req.url ~ "^/user$" ||
req.url ~ "^/user/.*$" ||
req.url ~ "^/flag/.*$" ||
req.url ~ "^.*/ajax/.*$" ||
req.url ~ "^.*/ahah/.*$") {
return (pass);
}
## BACKUP AND MIGRATE MODULE ##
# Backup and Migrate is a very popular Drupal module that needs to be excluded
# It won't work with Varnish
if (req.url ~ "^/admin/content/backup_migrate/export") {
return (pipe);
}
## COOKIES ##
# Remove cookies for stylesheets, scripts, and images used throughout the site.
# Removing cookies will allow Varnish to cache those files.
if (req.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico)(\?.*)?$") {
unset req.http.Cookie;
}
# Remove all cookies that are not necessary for Drupal to work properly.
# Since it would be cumbersome to REMOVE certain cookies, we specify
# which ones are of interest to us, and remove all others. In this particular
# case we leave SESS, SSESS and NO_CACHE cookies used by Drupal's administrative
# interface. Cookies in cookie header are delimited with ";", so when there are
# many cookies, the header looks like "Cookie1=value1; Cookie2=value2; Cookie3..."
# and so on. That allows us to work with ";" to split cookies into individual
# ones.
#
# The method for filtering unnecessary cookies has been adopted from:
# https://fourkitchens.atlassian.net/wiki/display/TECH/Configure+Varnish+3+for+Drupal+7
if (req.http.Cookie) {
# 1. We add ; to the beginning of cookie header
set req.http.Cookie = ";" + req.http.Cookie;
# 2. We remove spaces following each occurence of ";". After this operation
# all cookies are delimited with no spaces.
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
# 3. We replace ";" INTO "; " (adding the space we have previously removed) in cookies
# named SESS..., SSESS... and NO_CACHE. After this operation those cookies will be
# easy to differentiate from the others, because those will be the only one with space
# after ";"
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; \1=");
# 4. We remove all cookies with no space after ";", so basically we remove all cookies other
# than those above.
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
# 5. We strip leading and trailing whitespace and semicolons.
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
# If there are no cookies after our striping procedure, we remove the header altogether,
# thus allowing Varnish to cache this page
if (req.http.Cookie == "") {
unset req.http.Cookie;
}
# if any of our cookies of interest are still there, we disable caching and pass the request
# straight to Apache and Drupal
else {
return (pass);
}
}
}
. . .Die nächste Methode ist die. Diese Methode ist dafür verantwortlich, die Antwort von Apache und Drupal zu verarbeiten, bevor sie in den Cache gestellt oder aus dem Cache gelöscht wird. Wir können ändern, was Drupal sendet, um es in unsere Caching-Strategie zu integrieren.
Die Standardmethode sieht folgendermaßen aus:
. . .
sub vcl_backend_response {
# Happens after we have read the response headers from the backend.
#
# Here you clean the response headers, removing silly Set-Cookie headers
# and other mistakes your backend does.
}
. . .Ersetzen wir es durch diesen völlig neuen Block, wie er ist. Kommentare sind enthalten:
. . .
sub vcl_backend_response {
# Remove cookies for stylesheets, scripts and images used throughout the site.
# Removing cookies will allow Varnish to cache those files. It is uncommon for
# static files to contain cookies, but it is possible for files generated
# dynamically by Drupal. Those cookies are unnecessary, but could prevent files
# from being cached.
if (bereq.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico)(\?.*)?$") {
unset beresp.http.set-cookie;
}
}
. . .Der Code entfernt Cookies für statische Dateien mit der gleichen Methode wie zuvor, sodass Cookies für dieselben Dateien sowohl in als auch entfernt werden.
Speichern Sie die Konfigurationsdatei mit * STRG + x * und anschließend * y * gefolgt von * Eingabe *. Das Ändern anderer Methoden ist nicht erforderlich.
Schritt 5 - Lack neu starten
Starten Sie * Varnish * neu, damit die Änderungen wirksam werden:
sudo service varnish restartDer Lackserver sollte ohne Fehler neu starten.
Jetzt sollten Sie Ihre Drupal-Website wieder in Ihrem Browser anzeigen können.
Es gibt jedoch noch einen Schritt mehr, als wir erledigen sollten, bevor unsere Drupal-Site ordnungsgemäß zwischengespeichert wird. Wir müssen das Caching in Drupal aktivieren.
Schritt 6 - Cache in Drupal aktivieren
Standardmäßig sind bei Drupal die Cache-Mechanismen deaktiviert. Dies führt dazu, dass Header an Varnish gesendet werden, wodurch die Seiten überhaupt nicht zwischengespeichert werden. Ein deaktivierter Drupal-Cache verhindert automatisch, dass Varnish die Website beschleunigt.
Melden Sie sich als Administrator bei Ihrer Drupal-Site an, um das Drupal-Caching zu aktivieren.
Wählen Sie das Menü * Konfiguration * und dann * Leistung *.
image: https://assets.digitalocean.com/articles/drupal_varnish/1.png [Drupal-Konfigurationsmenü]
Suchen und überprüfen Sie im Abschnitt * Leistung * die Einstellungen für * Cache-Seiten für anonyme Benutzer * und * Cache-Blöcke *.
Stellen Sie die * minimale Cache-Lebensdauer * und den * Ablauf der zwischengespeicherten Seiten * auf einen vernünftigen Wert ein, z. B. * 30 Minuten *. Dieser Wert erhöht die Leistung erheblich und stellt dennoch sicher, dass der Cache nicht zu lange veraltet ist. Die beste Einstellung für die Cache-Lebensdauer hängt von der einzelnen Site ab und davon, wie oft sie aktualisiert wird. Klicken Sie nach dem Ändern der Werte auf * Konfiguration speichern *.
image: https://assets.digitalocean.com/articles/drupal_varnish/2.png [Cache-Einstellungen]
Damit ist die erforderliche Konfiguration abgeschlossen, damit Varnish unsere Drupal-Site zwischenspeichert.
Schritt 7 - Überprüfen der Lackkonfiguration
Um sicherzustellen, dass Varnish die Site zwischenspeichert, können wir das einfache Tool Is Varnish Working? Verwenden. Geben Sie die Adresse Ihrer Website in das Formular ein. Sie sollten eine Antwort wie die folgende sehen:
image: https://assets.digitalocean.com/articles/drupal_varnish/3.png [Arbeitslack]
Möglicherweise möchten Sie zweimal überprüfen, ob Sie die Meldung "Art" zum ersten Mal erhalten.
Weitere Lektüre
Die in diesem Artikel behandelten Themen sind nur die Spitze des Eisbergs. * Varnish * ist eine sehr leistungsfähige Software, die viel mehr kann als nur das einfache Cachen. Die offizielle Varnish-Dokumentation ist eine umfangreiche Ressource über die Möglichkeiten von Varnish und die VCL-Syntax. Um das Beste aus Varnish und Drupal herauszuholen, sollten Sie auch die eigenen Möglichkeiten von Drupal kennenlernen, um die Leistung zu verbessern. Die offizielle Drupal-Leistungsdokumentation ist ein guter Ausgangspunkt.
Lack ist ein Tool, das die Leistung Ihrer Website enorm steigern kann. Letztendlich ist es jedoch keine magische Lösung für alle Leistungsengpässe. Die besten Ergebnisse werden durch sorgfältige Planung in allen Phasen erzielt. Trotzdem kann selbst die einfachste * Varnish * -Konfiguration Ihre Site in wenigen Minuten schneller machen.