Lack konfigurieren
[Varnish Cache] ist ein Open-Source-Webanwendungsbeschleuniger (auch als HTTP-Beschleuniger“ „Caching HTTP Reverse Proxy bezeichnet). Varnish speichert (oder speichert) Dateien oder Fragmente von Dateien im Speicher, was Varnish in die Lage versetzt, die Antwortzeit und den Bandbreitenverbrauch bei zukünftigen, äquivalenten Anfragen zu reduzieren. Im Gegensatz zu Webservern wie Apache und Nginx wurde Varnish ausschließlich für die Verwendung mit dem HTTP-Protokoll entwickelt.
Systemanforderungen listet die unterstützten Versionen von Varnish auf.
Weitere Informationen zu Lack finden Sie unter:
- Das große Lackbild
- [Startoptionen lackieren]
- Lack- und Website-Performance
Lacktopologie-Diagramm
Die folgende Abbildung zeigt eine Grundansicht von Lack in Ihrer Commerce-Topologie.
In der vorherigen Abbildung führen HTTP-Anfragen von Benutzern über das Internet zu zahlreichen Anfragen für CSS, HTML, JavaScript und Bilder (zusammenfassend als "" bezeichnet. Lack befindet sich vor dem Webserver und leitet diese Anfragen an den Webserver weiter.
Wenn der Webserver Assets zurückgibt, werden zwischenspeicherbare Assets in Lack gespeichert. Alle nachfolgenden Anfragen für diese Assets werden von Varnish erfüllt (d. h. die Anfragen erreichen den Webserver nicht). Lack gibt zwischengespeicherte Inhalte extrem schnell zurück. Das Ergebnis sind schnellere Antwortzeiten, mit denen die Inhalte an die Benutzer zurückgegeben werden, und eine reduzierte Anzahl von Anfragen, die von Commerce erfüllt werden müssen.
Assets, das von Varnish zwischengespeichert wird, läuft in einem konfigurierbaren Intervall ab oder wird durch neuere Versionen derselben Assets ersetzt. Sie können den Cache auch manuell löschen, indem Sie entweder den Befehl Admin oder magento cache:clean
verwenden.
Prozessübersicht
In diesem Abschnitt wird beschrieben, wie Sie Varnish mit einem minimalen Parametersatz anfänglich installieren und testen, ob es funktioniert. Exportieren Sie dann eine Lackkonfiguration vom Commerce-Administrator und testen Sie sie erneut.
Der Prozess lässt sich wie folgt zusammenfassen:
-
Installieren Sie Varnish und testen Sie es, indem Sie auf eine beliebige Commerce-Seite zugreifen, um zu sehen, ob Sie HTTP-Antwort-Header erhalten, die anzeigen, dass Varnish funktioniert.
-
Installieren Sie die Commerce-Software und verwenden Sie den Administrator, um eine Varnish-Konfigurationsdatei zu erstellen.
-
Ersetzen Sie Ihre vorhandene Lackkonfigurationsdatei durch die vom Administrator erstellte.
-
Testen Sie alles noch einmal.
Wenn sich nichts in Ihrem
<magento_root>/var/page_cache
befindet, haben Sie Varnish erfolgreich mit Commerce konfiguriert!
-
Sofern nicht anders angegeben, müssen Sie alle in diesem Thema besprochenen Befehle als Benutzer mit
root
eingeben. -
Dieses Thema wurde für Varnish unter CentOS und Apache 2.4 geschrieben. Wenn Sie Varnish in einer anderen Umgebung einrichten, können einige Befehle unterschiedlich sein. Weitere Informationen finden Sie in der Lackdokumentation .
Bekannte Probleme
Wir kennen die folgenden Probleme mit Lack:
-
[Lack unterstützt SSL nicht]
Verwenden Sie alternativ eine SSL-Terminierung oder einen SSL-Terminierungs-Proxy.
-
Wenn Sie den Inhalt des
<magento_root>/var/cache
Verzeichnisses manuell löschen, müssen Sie Varnish neu starten. -
Mögliche Fehlermeldung bei der Installation von Commerce:
code language-none Error 503 Service Unavailable Service Unavailable XID: 303394517 Varnish cache server
Wenn dieser Fehler auftritt, bearbeiten Sie
default.vcl
und fügen Sie derbackend
wie folgt eine maximale Wartezeit hinzu:code language-conf backend default { .host = "127.0.0.1"; .port = "8080"; .first_byte_timeout = 600s; }
Übersicht über das Zwischenspeichern von Lacken
Das Zwischenspeichern von Lacken funktioniert mit Commerce mit:
nginx.conf.sample
aus dem GitHub-Repository von Magento 2.htaccess
verteilte Konfigurationsdatei für Apache in Commercedefault.vcl
Konfiguration für mit dem Admin generierten Lack
Bei der ersten Browser-Anfrage werden zwischenspeicherbare Assets von Varnish an den Client-Browser bereitgestellt und im Browser zwischengespeichert.
Darüber hinaus verwendet Varnish ein Entity Tag (ETag) für statische Assets. Mit dem ETag können Sie bestimmen, wann sich statische Dateien auf dem Server ändern. Daher werden statische Assets an den Client gesendet, wenn sie sich auf dem Server ändern - entweder auf eine neue Anforderung eines Browsers oder wenn der Client den Browser-Cache aktualisiert, normalerweise durch Drücken von F5 oder Strg+F5.
Weitere Informationen finden Sie in den folgenden Abschnitten.
Caching nach Browser-Anfrage
In diesem Abschnitt wird ein Browser-Inspektor verwendet, um zu zeigen, wie Assets in der ersten Anfrage an den Browser übermittelt und anschließend aus dem lokalen Browser-Cache geladen werden.
Erste Browser-Anfrage
nginx.conf.sample
und .htaccess
bieten Optionen für das Client-Caching. Wenn die erste Anfrage von einem Browser für ein zwischenspeicherbares Objekt gestellt wird, stellt Varnish es an den Client bereit.
Die folgende Abbildung zeigt ein Beispiel mit einem Browser-Inspektor:
Das vorherige Beispiel zeigt eine Anfrage für die Storefront-Hauptseite (m2_ce_my
). CSS- und JavaScript-Assets werden im Client-Browser zwischengespeichert.
Zweite Browser-Anfrage
Wenn derselbe Browser dieselbe Seite erneut anfordert, werden diese Assets aus dem lokalen Browser-Cache bereitgestellt, wie in der folgenden Abbildung dargestellt.
Beachten Sie den Unterschied in der Antwortzeit zwischen der ersten und der zweiten Anfrage. Auch hier weisen statische Assets einen Antwort-Code von 200 (OK) auf, da sie zum ersten Mal aus dem lokalen Cache bereitgestellt werden.
Verwendung von Etag in Commerce
Das folgende Beispiel zeigt Antwort-Header für ein bestimmtes statisches Asset.
calendar.css
verfügt über einen ETag-Antwort-Header, was bedeutet, dass die CSS-Datei im Client-Browser mit der Datei auf dem Server verglichen werden kann.
Darüber hinaus werden statische Assets mit dem HTTP-Status-Code 304 (Nicht geändert) zurückgegeben, wie in der folgenden Abbildung dargestellt.
Der 304-Status-Code tritt auf, weil der Benutzer seinen lokalen Cache ungültig gemacht hat und sich der Inhalt auf dem Server nicht geändert hat. Aufgrund des 304-Status-Codes wird das statische Asset content nicht übertragen. Nur HTTP-Kopfzeilen werden in den Browser heruntergeladen.
Wenn sich der Inhalt auf dem Server ändert, lädt der Client das statische Asset mit einem HTTP-Status-Code 200 (OK) und einem neuen E-Tag herunter.