Hochleistungs-Caching mit NGINX und NGINX Plus

Dieser Beitrag basiert auf einem Webinar von Owen Garrett, eingeleitet von Andrew Alexeev.

Inhaltsverzeichnis

Einführung

Inhaltscaching und NGINX

Caching steuern

Fragen und Antworten

0:00 Einführung

Andrew Alexeev : Willkommen zu unserem neuesten Webinar. Mein Name ist Andrew. NGINX wurde von Igor Sysoev mit der Idee geschrieben, die Websites der Welt schneller zu machen, reaktionsschneller zu gestalten und leichter skalierbar zu machen. Heute basiert NGINX auf über 30 % der Top-Sites und über 20 % aller Websites im Internet. [ Anm.: Diese Statistiken galten zum Zeitpunkt des Webinars im Mai 2014; die aktuellen Werte finden Sie hier . ] Ich hoffe, Sie finden den Inhalt dieses Webinars nützlich und anwendbar auf Ihre bestehende oder geplante NGINX-Umgebung.

Gestatten Sie mir, Ihnen jetzt Owen Garrett vorzustellen. Owen ist hier bei NGINX für die Produktentwicklung verantwortlich. Heute wird Owen darüber sprechen, wie Sie leistungsstarke Caching-Mechanismen in NGINX anwenden können, um Ihre Anwendung von der Last zu befreien, immer wieder sich wiederholende Inhalte zu generieren.

1:22 Über dieses Webinar

Owen Garrett : Vielen Dank, Andrew, und Leute, vielen Dank, dass Sie in den nächsten 45 oder 50 Minuten bei uns sind. Ich erkläre Ihnen, wie NGINX im Hinblick auf die Inhaltszwischenspeicherung funktioniert. Wir sehen uns einige Möglichkeiten zur Leistungssteigerung an und gehen etwas genauer darauf ein, wie die Inhaltszwischenspeicherung wirklich funktioniert, damit Sie für die Fehlerbehebung und Diagnose der Vorgänge in NGINX gerüstet sind. Abschließend gebe ich Ihnen einige nützliche Hinweise und Tipps, damit Sie eine wirklich detaillierte Kontrolle darüber haben, was NGINX mit Inhalten macht, die zwischengespeichert werden können.

Alle zielen auf die gleichen Kerngründe ab, wie Andrew sie beschrieben hat: Ihre Upstream-Server von der Belastung durch die Generierung sich wiederholender Inhalte zu entlasten, damit sie für die Ausführung der Anwendungen frei sind, die Ihr Unternehmen wirklich benötigt. Erweitern Sie die Anzahl dieser Server, um Ihren Endbenutzern ein besseres Serviceniveau zu bieten und die Zuverlässigkeit Ihres Dienstes angesichts großer Verkehrsspitzen aus dem Internet und potenzieller Ausfälle von Upstream-Servern zu erhöhen.

2:17 Grundprinzipien des Inhalts-Caching

Bevor wir auf die Implementierungskonfiguration von NGINX eingehen, möchte ich kurz die Funktionsweise des Inhalts-Cachings wiederholen, damit wir alle auf derselben Seite und mit derselben Basis an Kerninformationen beginnen.

2:35 Grundprinzipien

Das Grundprinzip der Inhaltszwischenspeicherung besteht darin, die Upstream-Server von sich wiederholenden Arbeiten zu entlasten. Wenn der erste Benutzer einen Inhalt auf der Website anfordert (dargestellt durch das blaue Symbol und die blauen Linien), wird seine HTTP-Anfrage an NGINX und von dort an den Upstream-Server (grau auf der rechten Seite) weitergeleitet.

Die Antwort wird an den Remote-Benutzer zurückgeleitet, aber wenn sie zwischengespeichert werden kann (und wir werden gleich darüber sprechen, was das bedeutet), speichert NGINX eine Kopie dieser Antwort. Wenn ein anderer Benutzer, der orangefarbene Typ, vorbeikommt und denselben Inhalt anfordert, kann NGINX diesen direkt aus seinem lokalen Cache bereitstellen, anstatt die Anforderung vom Upstream-Server zu fälschen.

Dieses Grundprinzip der Speicherung zwischenspeicherbarer, unveränderlicher Inhalte wird von Ihrem Webbrowser, von einem CDN, den von Ihnen aufgerufenen Websites, externen CDNs und von NGINX auf anderen Geräten verwendet. Es fungiert als Reverse-Proxy- Cache und wird normalerweise im Rechenzentrum oder in der Cloud neben den Ursprungsservern bereitgestellt, auf denen Ihre Webinhalte und Webanwendungen gehostet werden.

3:59 Mechanik des HTTP-Caching

Der Ursprungsserver deklariert die Cachefähigkeit von Inhalten mithilfe eines oder mehrerer gut verstandener und bekannter HTTP-Antwortheader. Natürlich können Caching-Server dieses Verhalten ignorieren, überschreiben oder ändern. Um die konfigurierte Inhaltszwischenspeicherung zu verstehen, müssen Sie sich zunächst einmal gut damit auskennen, wie ein Ursprungsserver anzeigt, dass Inhalte zwischengespeichert werden können und unveränderlich sind, und dass die [zwischengespeicherte] Kopie eine bestimmte Lebensdauer hat.

Das Zwischenspeichern von Inhalten begann mit einem einfachen HTTP-Antwortheader namens Expires . Der Ursprungsserver präsentiert einige Inhalte und erklärt, dass diese bis zu dem im Header „Expires“ angegebenen Datum gültig sind. Diese Methode wurde schnell durch eine effektivere und flexiblere Methode ersetzt – den Cache-Control- Header.

Die Verwendung von „Expires“ ist etwas umständlich und ineffizient. Daten müssen richtig formatiert und analysiert werden, wohingegen Cache-Control viel stärker rationalisiert und auf die Anforderungen und die Geschwindigkeit von Inhaltscaches abgestimmt ist. Cache-Control deklariert Inhalte als öffentlich oder privat und deklariert, wenn sie öffentlich sind, ein Höchstalter – die Anzahl der Sekunden, die sie zwischengespeichert werden können, bevor das Caching-Objekt den Inhalt erneut anfordern muss.

Der dritte Header, der das Caching direkt steuert, ist X-Accel-Expires . Dieser Header ist speziell für NGINX; nur NGINX versteht ihn und er wird verwendet, wenn Sie das Verhalten der obigen Header überschreiben und NGINX direkt mitteilen möchten, wie lange ein Inhaltselement genau zwischengespeichert werden soll.

In manchen Situationen möchten Sie, dass der Webbrowser Inhalte für einen längeren Zeitraum zwischenspeichert, Sie sind jedoch damit zufrieden, dass der Proxy-Cache (NGINX vor dem Ursprungsserver) die Inhalte für einen kürzeren Zeitraum zwischenspeichert, damit Änderungen schneller übernommen und an neue Clients weitergegeben werden, während alte Clients die Inhalte nicht unnötig erneut anfordern.

Diese Methode kann jedoch auch mit den letzten beiden Headern implementiert werden. Ein Ursprungsserver kann angeben, wann ein Inhaltselement zuletzt geändert wurde, und er kann ein sogenanntes ETag (Entity Tag) angeben – eine undurchsichtige Zeichenfolge, häufig ein Hash-Wert, der diesen Inhalt identifiziert.

Clients können dann Anfragen mit bedingten GETs stellen. Sie können in ihre Anfrage einen If-Modified-Since- oder If-None-Match- Header aufnehmen. Dadurch erklärt der Client, dass er über eine zwischengespeicherte Version des Inhalts verfügt, der zuletzt an einem bestimmten Datum geändert wurde oder über einen bestimmten ETag verfügt. Wenn die neueste Version, die der Server hält, mit der Version des Clients übereinstimmt, antwortet der Server einfach mit einem 304Nicht geändert . Dies ist eine schnelle Reaktion, die Netzwerkbandbreite spart und es dem Client ermöglicht, in aller Ruhe zu prüfen, ob die zwischengespeicherte Kopie des Inhalts noch gültig ist.

Diese fünf Header definieren aus der Sicht eines Ursprungsservers, wie Inhalt zwischengespeichert werden kann – seine Gültigkeit, seine Aktualität und, in Bezug auf das ETag , die Details des Inhalts selbst.

7:46 Was speichert NGINX im Cache?

Proxy-Caches wie NGINX können relativ frei interpretieren, wie streng sie diese Header einhalten. Natürlich sollten sie nichts zwischenspeichern, was nicht zwischengespeichert werden kann, aber sie sind selbstverständlich nicht dazu verpflichtet, etwas zwischenzuspeichern, wenn der Ursprungsserver angibt, dass es zwischengespeichert werden kann.

Das grundlegende Verhalten von NGINX besteht darin, alle GET- und HEAD- Anfragen zwischenzuspeichern, die vom Ursprungsserver als zwischenspeicherbar gekennzeichnet werden, vorausgesetzt, die Antwort enthält keine Set-Cookie -Header. Das liegt daran, dass Set-Cookie -Header typischerweise eindeutige, für jede Anforderung spezifische Daten enthalten und es standardmäßig nicht angebracht wäre, diesen Wert zwischenzuspeichern.

NGINX speichert jede Ressource mit einem bestimmten Schlüssel im Cache – einem Cache-Schlüssel. Alle Anfragen, die denselben Cache-Schlüssel generieren, werden mit derselben Ressource erfüllt. Standardmäßig wird der Cache der Roh-URL oder in der Konfiguration der auf dieser Folie dargestellten Zeichenfolge [ $scheme$proxy_host$uri$is_args$args ] zugeordnet. Wenn NGINX Inhalte zwischenspeichert, wird [die Gültigkeitsdauer] (in der Reihenfolge der Präferenz) durch den Header „X-Accel-Expires“ (sofern vorhanden) oder den Header „Cache-Control“ bzw. den alten „Expires“ -Header definiert.

Sie können NGINX so einstellen, dass bestimmte dieser Header maskiert werden oder stattdessen eine feste Cache-Zeit bereitgestellt wird, völlig unabhängig von der Aussage des Ursprungsservers. Als Referenz definiert RFC 2616 das gewünschte Verhalten eines Proxy-Cache in Bezug auf HTTP.

Dies gibt Ihnen einen kurzen Eindruck von der Universalität des Caching und dem grundlegenden Standardverhalten von NGINX beim Caching von Inhalten, die normalerweise sicher zwischengespeichert werden können, um Ihre Website zu beschleunigen und Ihre Ursprungsserver zu entlasten.

9:55 NGINX im Betrieb

Werfen wir nun einen kurzen Blick auf NGINX im Betrieb. Es ist wirklich sehr einfach, NGINX so zu konfigurieren, dass die Inhaltszwischenspeicherung aktiviert wird.

10:06 NGINX-Konfiguration

Es handelt sich dabei um ein paar Zeilen in Ihrer NGINX-Konfigurationsdatei – eine zum Erstellen eines Cache auf der Festplatte mit einem bestimmten Parametersatz, der die Anordnung der Dateien, die Ablaufzeit [für Objekte in diesem Cache] und die Größe dieses Caches angibt. Die zweite Direktive, die Proxy_Cache- Direktive, wird dann mit einem NGINX-Proxy verknüpft und teilt ihm mit, dass der Inhalt (Ergebnisse, Antworten) in einem benannten Cache zwischengespeichert werden soll.

Also habe ich hier einen Cache mit dem Namen „eins“ erstellt. Er hat eine Speichergröße von 10 MB für Metadaten, aber eine unbegrenzte Größe auf der Festplatte für zwischengespeicherte Inhalte. Inhalte werden zwischengespeichert und dann wiederhergestellt, wenn sie 60 Minuten lang inaktiv waren. Dieser Cache namens 1 wird von unserem Standardserver verwendet. Diese beiden [Direktiven], proxy_cache_path und proxy_cache , reichen aus, um ein zuverlässiges, konsistentes Caching für einen Proxyserver in NGINX zu ermöglichen.

11:14 Caching-Prozess

Der Prozess, den NGINX durchläuft, wenn es eine Anfrage empfängt und einen Cache abfragt, ist wie folgt definiert. Wir beginnen mit dem Lesen einer Anfrage (oberes linkes Feld auf dieser Folie) und setzen den Cache-Schlüssel mit der Roh-URI und den anderen Parametern zusammen, die wir zum Identifizieren der dieser Anfrage entsprechenden Ressource verwenden werden. Anschließend überprüfen wir den Cache auf der Festplatte, indem wir auf die Metadaten im Speicher zugreifen, um festzustellen, ob wir eine gültige, aktuelle Kopie der Antwort auf diese Anfrage haben.

Wenn uns das gelingt, zählt das als Treffer. Dann kann NGINX direkt aus dem Cache antworten. Es antwortet aus dem Cache, indem es den Inhalt von der Festplatte bereitstellt, genau so, wie NGINX statischen Inhalt bereitstellt. So erhalten Sie das Maß an Leistung, Zuverlässigkeit und Skalierbarkeit, für das NGINX entwickelt wurde. Bei statischen Inhalten erhalten Sie genau dasselbe Maß [an Leistung], wenn Sie Inhalte aus dem Inhaltscache von NGINX bereitstellen.

Andererseits kann es beim Prüfen des Caches zu einem Cachefehler kommen. Dies bedeutet, dass der Inhalt nicht im Cache vorhanden ist oder dass der Inhalt im Cache veraltet ist und aktualisiert werden muss. Im einfachsten Fall bedeutet dieser Fehler, dass wir den Inhalt vom Ursprungsserver anfordern, die Antwort erhalten und prüfen, ob er zwischengespeichert werden kann.

Wenn dies der Fall ist, streamen wir es auf die Festplatte, genau wie NGINX es für jede große Antwort tut, die im Proxy-Modus verarbeitet wird. Sobald die Antwort auf die Festplatte gestreamt wurde, kopieren wir sie in den Cache und antworten direkt aus dem Cache. Eine der Herausforderungen bei diesem Ansatz besteht darin, dass NGINX mehrere Anfragen für denselben Inhalt gleichzeitig erhält und alle fehlschlagen.

Normalerweise leitet NGINX alle diese Anfragen an den Ursprungsserver weiter und könnte diesen dadurch überlasten – insbesondere bei Anfragen, deren Antwortgenerierung lange dauert. Aus diesem Grund können Sie eine Cache-Sperre verwenden. Die Direktive „proxy_cache_lock“ stellt sicher, dass beim Aktualisieren eines Inhalts immer nur eine Anfrage gleichzeitig an den Upstream-Server gesendet wird.

In dem von mir beschriebenen Szenario würde die erste Anfrage an den Upstream-Server gehen, die restlichen Anfragen für denselben Inhalt würden jedoch zurückgehalten, bis entweder die Antwort übermittelt und in den Cache eingefügt wurde (an diesem Punkt können alle Anfragen erfüllt werden) oder ein Timeout erreicht wird [festgelegt durch die Direktive proxy_cache_lock_timeout ] – NGINX hat lange genug gewartet, bis Inhalte vom Server zurückkommen, und an diesem Punkt werden die von Ihnen freigegebenen Anfragen an den Ursprungsserver weitergeleitet.

Mit der Proxy-Cache-Sperre und dem Timeout haben Sie eine leistungsstarke Kontrolle darüber, dass Sie bei einer stark ausgelasteten Site mit vielen Anfragen für denselben Inhalt den Ursprungsserver nicht plötzlich durch mehrere Anfragen überlasten, wenn dieser Inhalt im Cache abläuft.

Es gibt noch ein weiteres Element des Caching-Prozesses in NGINX, das nicht sauber in dieses Flussdiagramm passt, da es fast jede Phase des Diagramms abdeckt. Dies ist die Funktion, die mit der Direktive „proxy_cache_use_stale“ konfiguriert wird. Wenn einer dieser Schritte aus irgendeinem Grund zu irgendeinem Zeitpunkt fehlschlägt, z. B. wenn wir beim Aktualisieren des Inhalts eine Zeitüberschreitung erreichen oder eine fehlerhafte Antwort vom Upstream-Server oder ein anderer Fehlertyp auftritt, haben wir die Möglichkeit, direkt aus dem Cache zu antworten, selbst wenn der zwischengespeicherte Inhalt veraltet ist.

Dies ist ein wirklich leistungsfähiges Tool für den Fall, dass Ihre Upstream-Server durch den Datenverkehr überlastet sind oder aufgrund von Wartungsarbeiten oder eines katastrophalen Fehlers ausfallen. Dadurch wird sichergestellt, dass NGINX Ihre Inhalte unter Verwendung der veralteten Inhalte aus dem Cache weiterhin bereitstellen kann, anstatt eine Fehlermeldung an den Client zurückzugeben.

15:32 Caching ist nicht nur für HTTP

Das Caching in NGINX ist nicht nur für HTTP. NGINX ist viel mehr als nur ein HTTP-Proxy, der Anfragen an vorgelagerte Webserver weiterleitet. Im Allgemeinen dienen diese Upstream-Webserver zur Schnittstelle mit APIs wie FastCGI oder SCGI. NGINX kann dies direkt in einer Proxy-Manier tun, die dem HTTP-Proxy sehr ähnlich ist.

NGINX kann seine Caching-Techniken für HTTP-Proxys , FastCGI-Proxys , uWSGI-Proxys und SCGI-Proxys einsetzen. Alle funktionieren ähnlich wie der HTTP-Proxy, mit auf der Festplatte gespeicherten Caches und direkten Antworten, sodass keine Proxy-Verbindung zu diesen Upstream-Diensten erforderlich ist.

NGINX kann auch mit einem Memcached-Server interagieren. Dies ist ein etwas anderer Caching-Ansatz. In diesem Fall speichert NGINX Inhalte nicht direkt, sondern verwendet Memcached als Proxy und verlässt sich auf einen externen Agenten, um Memcached mit den benötigten Inhalten zu füllen. Dies kann ein weiteres nützliches Tool sein, und es gibt viele Möglichkeiten, Memcached bei Bedarf von einer externen Site aus zu füllen. Sie könnten dies als eine Möglichkeit betrachten, einen Cache für NGINX zu füllen, wenn dies Ihre geschäftliche Anforderung ist.

17:10 So verstehen Sie, was vor sich geht

Das Caching kann möglicherweise sehr komplex sein, wenn Sie über eine große Infrastruktur mit mehreren Ebenen verfügen, von denen einige Caching durchführen, andere nicht, einige Inhalte generieren und andere nicht. In diesem Fall kann es eine ziemliche Herausforderung sein, den Überblick darüber zu behalten, was vor sich geht – woher die Inhalte kommen – und auftretende Probleme zu diagnostizieren und zu beheben. In NGINX machen wir es Ihnen so einfach wie möglich.

17:38 Cache-Instrumentierung

Mithilfe einiger ausgefeilter Instrumente können Sie die Instrumentierung dynamisch steuern, um zu verfolgen, woher der Inhalt kommt, wo er im Cache gespeichert ist und welchen Status er im Cache hat.

Der erste Schritt ist die Variable $upstream_cache_status , die für jede Anfrage berechnet wird, auf die NGINX geantwortet hat, unabhängig davon, ob sie aus dem Cache stammt oder nicht. Und Sie fügen den Wert dieser Variable mithilfe der Direktive „add_header“ kontinuierlich zu Ihrer Antwort hinzu. Normalerweise fügen wir diesen Wert in einen X-Cache-Status- Header in der Antwort ein. Es kann einen von sieben verschiedenen Werten annehmen, die angeben, wie dieser Inhalt bereitgestellt wurde. Ob der Cache umgangen wurde, ob es von einer erneuten Validierung stammte, ob es ein Treffer war.

Dies ist Ihr erster Schritt, um zu verstehen, woher Ihre Antworten kommen. Kommen sie aus dem lokalen NGINX-Cache oder von einem Upstream-Server? Und Sie können diesen Antwortheader auf verschiedene Weise überprüfen – über die Befehlszeile mit Tools wie curl oder, was sehr häufig vorkommt, in Ihrem Webbrowser mithilfe interaktiver Debugger.

Natürlich möchten Sie diesen Wert möglicherweise nicht allen Endbenutzern mitteilen. Sie sollten beim Einfügen dieses Wertes in die Header-Antwort selektiv vorgehen.

19:08 Cache-Instrumentierung (Forts.)

Die Konfigurationssprache von NGINX bietet Ihnen die Flexibilität, selektiv vorzugehen. Dieses Beispiel zeigt nur eine der vielen Möglichkeiten, wie Sie dies tun können. Wir nehmen die Remote-Adresse und wenn es sich zufällig um localhost handelt, dann setzen wir den $upstream_cache_status in eine temporäre Variable ( $cache_status ). Wenn wir schließlich eine Antwort zurückgeben, fügen wir eine temporäre Variable in die Antwort ein.

Auf diese Weise wird nur Anfragen von ausgewählten IP-Adressen der Wert der Variable $upstream_cache_status angezeigt. Sie können noch viele andere Dinge tun. Wir werden uns gleich ansehen, wie Inhalte auf der Festplatte gespeichert werden. Sie können den Schlüssel, der zur Berechnung des Speicherorts auf der Festplatte verwendet wird, in die Antwort einfügen. Sie können alle möglichen Parameter in die Antwort einfügen, die Ihnen bei der Diagnose des Caches während der Ausführung helfen.

20:09 Cache-Status

NGINX Plus , unsere kommerzielle Version von NGINX, bietet eine Reihe zusätzlicher Funktionen, die bei Anwendungsfällen wie dem Caching hilfreich sind. NGINX Plus ist eine kommerziell unterstützte Version von NGINX, die von unserem Ingenieurteam in Moskau erstellt und einer Reihe umfassender Regressionstests unterzogen wurde, um den korrekten Betrieb sicherzustellen.

NGINX Plus enthält außerdem zahlreiche Funktionen, die sich an Unternehmen richten, die NGINX als Reverse-Proxy und Load Balancer verwenden möchten. Funktionen rund um Lastausgleich, Integritätsprüfungen, erweitertes Video-Streaming. Und in diesem Zusammenhang Funktionen rund um erweiterten Status, bessere Diagnose und Visualisierung dessen, was in NGINX passiert.

[Editor – Die Folie oben und der folgende Absatz wurden aktualisiert, um auf die NGINX Plus API zu verweisen, die das ursprünglich hier besprochene separate Statusmodul ersetzt und veraltet.]

Für eine Demo können Sie auf demo.nginx.com/dashboard.html gehen. Dort wird eine Webseite angezeigt, auf der die Statusdaten angezeigt werden, die von NGINX Plus mithilfe der NGINX Plus-API veröffentlicht werden. Wenn Sie den angegebenen Curl -Befehl ausführen, werden die JSON-Rohdaten angezeigt, die direkt aus der NGINX Plus-Binärdatei übernommen werden (hier werden sie an das Dienstprogramm jq weitergeleitet, um jedes Element in eine eigene Zeile zu setzen und hierarchisch einzurücken).

In diesen JSON-Daten finden Sie Echtzeitdaten zum Status jedes einzelnen Caches in Ihrer NGINX Plus-Bereitstellung. Dies gibt Ihnen zusammen mit der Variable „$upstream_cache_status“ und den anderen Möglichkeiten, mit denen Sie den Cache instrumentieren können, einen wirklich guten Überblick darüber, wie NGINX Inhalte zwischenspeichert, und ermöglicht Ihnen, in einzelne Anfragen einzusteigen, um herauszufinden, ob diese Anfrage aus dem Cache kam oder nicht, und den aktuellen Status im Cache.

21:57 So funktioniert das Content-Caching in NGINX

Nachdem wir uns nun angesehen haben, wie wir das Kontakt-Caching von außen untersuchen können, wollen wir es nun von innen betrachten. Wie funktioniert es innerhalb von NGINX? Wie ich bereits erwähnt habe, funktioniert der Inhaltscache in NGINX ähnlich wie die Handhabung von Dateien auf der Festplatte. Sie erhalten dieselbe Leistung, dieselbe Zuverlässigkeit und dieselben Betriebssystemoptimierungen, wenn Sie Inhalte aus unserem Inhaltscache bereitstellen, wie wenn Sie statische Inhalte bereitstellen – die Leistung, für die NGINX bekannt ist.

22:40 So funktioniert es

Der Inhaltscache wird in einem dauerhaften Cache auf der Festplatte gespeichert. Wir arbeiten mit dem Betriebssystem zusammen, um den Festplattencache in den Arbeitsspeicher auszulagern und geben dem Seitencache des Betriebssystems Hinweise, welche Inhalte im Arbeitsspeicher abgelegt werden sollen. Dies bedeutet, dass wir Inhalte aus dem Cache bereitstellen können, wenn dies erforderlich ist.

Die Metadaten zum Cache, Informationen darüber, was sich dort befindet und wann es abläuft, werden in einem gemeinsam genutzten Speicherbereich für alle NGINX-Prozesse separat gespeichert und sind immer im Speicher vorhanden. NGINX kann den Cache also extrem schnell abfragen und durchsuchen. Es muss nur auf den Seitencache zugreifen, wenn es die Antwort abrufen und sie dem Endbenutzer zurückgeben muss.

Wir werden uns ansehen, wie Inhalte im Cache gespeichert werden, wir werden uns ansehen, wie dieser persistente Cache beim Start in leere NGINX-Arbeitsprozesse geladen wird, wir werden uns einige der Wartungsarbeiten ansehen, die NGINX automatisch am Cache durchführt, und wir runden das Ganze ab, indem wir uns ansehen, wie Sie in bestimmten Situationen Inhalte manuell aus dem Cache entfernen können.

23:53 Wie werden zwischengespeicherte Inhalte gespeichert?

Sie erinnern sich, dass der Inhaltscache mit einer Direktive namens proxy_cache_path deklariert wird. Diese Anweisung gibt die Anzahl der Parameter an: wo der Cache in Ihrem Dateisystem gespeichert ist, den Namen des Cache, die Größe des Cache im Speicher für die Metadaten und die Größe des Cache auf der Festplatte. In diesem Fall gibt es einen 40 MB großen Cache auf der Festplatte.

Der Schlüssel zum Verständnis, wo der Inhalt gespeichert ist, ist das Verständnis des Cache-Schlüssels – der eindeutigen Kennung, die NGINX jeder zwischenspeicherbaren Ressource zuweist. Standardmäßig wird diese Kennung aus den grundlegenden Parametern der Anforderung erstellt: dem Schema, dem Host -Header, der URI und allen String-Argumenten.

Sie können dies jedoch erweitern, wenn Sie Dinge wie Cookie-Werte oder Authentifizierungsheader oder sogar Werte verwenden möchten, die Sie zur Laufzeit berechnet haben. Vielleicht möchten Sie für Benutzer in Großbritannien unterschiedliche Versionen speichern als für Benutzer in den USA. Dies alles ist durch die Konfiguration der Direktive proxy_cache_key möglich.

Wenn NGINX eine Anfrage bearbeitet, berechnet es den Proxy-Cache-Schlüssel und aus diesem Wert dann eine MD5-Summe. Sie können dies selbst reproduzieren, indem Sie das Befehlszeilenbeispiel verwenden, das ich weiter unten auf der Folie gezeigt habe. Wir nehmen den Cache-Schlüssel httplocalhost:8002/time.php und pumpen diesen durch md5sum . Achten Sie darauf, dass Sie nicht gleichzeitig eine neue Zeile durchpumpen, wenn Sie dies von der Shell aus tun.

Dadurch wird der MD5-Hash-Wert berechnet, der diesem zwischenspeicherbaren Inhalt entspricht. NGINX verwendet diesen Hash-Wert, um den Speicherort auf der Festplatte zu berechnen, an dem der Inhalt gespeichert werden soll. Sie sehen im Proxy-Cache-Pfad , dass wir einen zweistufigen Cache mit einem einstelligen und dann einem zweistelligen Verzeichnis angeben. Wir ziehen diese Zeichen vom Ende der Zeichenfolge ab, um ein Verzeichnis namens4 und ein Unterverzeichnis namens 9b , und dann legen wir den Inhalt des Caches (plus die Header und eine kleine Menge an Metadaten) in einer Datei auf der Festplatte ab.

Sie können das Inhalts-Caching testen. Sie können den Cache-Schlüssel als einen der Antwort-Header ausdrucken und ihn durch md5sum pumpen, um die Hash-Entsprechung dieses Werts zu berechnen. Anschließend können Sie den Wert auf der Festplatte überprüfen, um festzustellen, ob er wirklich vorhanden ist, und die von NGINX zwischengespeicherten Header, um zu verstehen, wie das alles zusammenpasst.

26:36 Cache von der Festplatte laden

Da der Inhalt nun auf der Festplatte gespeichert und persistent ist, muss NGINX diesen Inhalt beim Start in den Speicher laden – oder besser gesagt, es muss sich durch den Festplattencache arbeiten, die Metadaten extrahieren und die Metadaten dann in den Speicher im gemeinsam genutzten Speichersegment laden, das von jedem der Arbeitsprozesse verwendet wird. Dies geschieht mithilfe eines Prozesses namens Cache Loader .

Beim Start wird ein Cache Loader gestartet und einmal ausgeführt. Dabei werden die Metadaten in kleinen Blöcken auf die Festplatte geladen: 100 Dateien gleichzeitig, in einer Sandbox auf 200 ms begrenzt, dazwischen 50 ms pausieren und dann wiederholen, bis der gesamte Cache durchgearbeitet und das gemeinsam genutzte Speichersegment aufgefüllt ist.

Der Cache Loader wird dann beendet und muss nicht erneut ausgeführt werden, es sei denn, NGINX wird neu gestartet oder neu konfiguriert und das gemeinsam genutzte Speichersegment muss erneut initialisiert werden. Sie können die Funktionsweise des Cache Loaders optimieren, was sinnvoll sein kann, wenn Sie über sehr schnelle Festplatten und eine geringe Auslastung verfügen. Sie können die Geschwindigkeit erhöhen oder die Geschwindigkeit vielleicht etwas verringern, wenn Sie einen Cache mit einer großen Anzahl von Dateien und langsamen Festplatten speichern und nicht möchten, dass der Cache Loader beim Start von NGINX übermäßig viel CPU-Leistung verbraucht.

28:07 Verwalten des Festplattencaches

Sobald sich der Cache im Speicher befindet und die Dateien auf der Festplatte gespeichert sind, besteht das Risiko, dass zwischengespeicherte Dateien, auf die nie zugegriffen wird, für immer dort hängen bleiben. NGINX speichert sie beim ersten Mal, wenn es sie sieht, aber wenn keine weiteren Anforderungen für eine Datei vorliegen, bleibt [die Datei] einfach dort auf der Festplatte, bis etwas kommt und sie bereinigt.

Dabei handelt es sich um den Cache-Manager . Er wird regelmäßig ausgeführt, entfernt Dateien von der Festplatte, auf die innerhalb eines bestimmten Zeitraums nicht zugegriffen wurde, und löscht Dateien, wenn der Cache zu groß ist und seine angegebene Größe überschritten hat. Sie werden in der Reihenfolge gelöscht, in der sie zuletzt verwendet wurden. Sie können diesen Vorgang mit Parametern für die [Direktive] proxy_cache_path konfigurieren, genau wie Sie den Cache Loader konfigurieren:

• Die Inaktivitätszeit beträgt standardmäßig 10 Minuten.
• Der Parameter „max-size“ hat keine Standardbegrenzung. Wenn Sie für den Cache eine maximale Größenbeschränkung festlegen, kann dieser zeitweise überschritten werden. Beim Ausführen des Cache-Managers werden jedoch die am wenigsten verwendeten Dateien gelöscht, um den Cache wieder unter diese Beschränkung zu bringen.

29:22 Inhalte von der Festplatte löschen

Schließlich gibt es Situationen, in denen Sie möglicherweise Inhalte von der Festplatte löschen möchten. Sie möchten eine Datei suchen und löschen. Das ist relativ einfach, wenn Sie die Techniken kennen, die wir zuvor besprochen haben – Ausführen des Cache-Schlüssels über md5sum – oder einfach ein rekursives grep über das Dateisystem ausführen, um zu versuchen, die Datei(en) zu identifizieren, die Sie löschen möchten.

Wenn Sie NGINX Plus verwenden, können Sie alternativ die in dieses Produkt integrierte Cache-Bereinigungsfunktion nutzen. Mit der Cache-Bereinigungsfunktion können Sie einen bestimmten Parameter aus der Anforderung übernehmen. Im Allgemeinen verwenden wir eine Methode namens PURGE , um zu identifizieren, dass es sich um eine Cache-Bereinigungsanforderung handelt.

Das Löschen wird von einem speziellen NGINX Plus-Handler durchgeführt, der die URI prüft und alle Dateien, die mit dieser URI übereinstimmen, aus dem Cache löscht. Der URI kann ein Sternchen angehängt werden, sodass sie zu einem Stamm wird. In diesem Fall verwenden wir die Bereinigungsfunktion, um jede einzelne Datei zu löschen, die vom lokalen Host-Port 8001 bereitgestellt wird. Sie können aber natürlich auch Unterverzeichnisse angeben.

Unabhängig davon, welche Methode Sie verwenden, können Sie jederzeit sicher Dateien aus dem Cache auf der Festplatte löschen oder sogar mit rm -rf das gesamte Cache-Verzeichnis aufrufen. NGINX lässt sich nicht aus der Ruhe bringen und prüft fortlaufend, ob Dateien auf der Festplatte vorhanden sind. Wenn sie fehlen, entsteht ein Cache-Miss. NGINX ruft dann den Cache vom Ursprungsserver ab und speichert ihn wieder im Cache auf der Festplatte. So ist es immer sicher, zuverlässig und stabil, wenn Sie einzelne Dateien aus dem Cache löschen müssen.

31:27 Caching steuern

Wir haben uns also angeschaut, wie das Caching funktioniert, wir haben uns die Implementierung in NGINX angesehen und sind ausführlich darauf eingegangen, wie Dateien auf der Festplatte gespeichert werden, um die gleiche Leistung zu erzielen wie bei statischen Inhalten. Lassen Sie uns nun etwas schlauer auf das Caching eingehen.

Für einfache Sites können Sie das Caching aktivieren. Im Allgemeinen führt es genau das aus, was es tun soll, um Ihnen weiterhin die gewünschte Leistung und das gewünschte Cache-Verhalten zu bieten. Es müssen jedoch immer Optimierungen vorgenommen werden und es gibt häufig Situationen, in denen das Standardverhalten nicht mit dem gewünschten Verhalten übereinstimmt.

Möglicherweise setzen Ihre Ursprungsserver nicht die richtigen Antwortheader oder Sie möchten die Angaben in NGINX selbst überschreiben. Es gibt unzählige Möglichkeiten, wie Sie NGINX konfigurieren können, um die Caching-Funktion zu optimieren.

32:30 Verzögertes Caching

Sie können das Caching verzögern. Dies kommt sehr häufig vor, wenn Sie über einen großen Bestand an Inhalten verfügen, auf die größtenteils nur ein- oder zweimal pro Stunde oder pro Tag zugegriffen wird. Wenn Ihre Firmenbroschüre von nur sehr wenigen Leuten gelesen wird, ist der Versuch, den Inhalt zwischenzuspeichern, oft Zeitverschwendung. Durch verzögertes Caching können Sie ein Wasserzeichen einfügen. Eine zwischengespeicherte Version dieses Inhalts wird nur dann gespeichert, wenn er eine bestimmte Anzahl von Anfragen erhielt. Solange Sie das Grenzwert von „proxy_cache_min_uses“ nicht erreicht haben, wird keine Version im Cache gespeichert.

Dadurch können Sie gezielter entscheiden, welche Inhalte in Ihren Cache gelangen. Der Cache selbst ist eine begrenzte Ressource, die normalerweise durch die Speichermenge begrenzt ist, die Sie auf Ihrem Server haben, da Sie sicherstellen möchten, dass der Cache so weit wie möglich in den Speicher ausgelagert wird. Daher möchten Sie oft bestimmte Inhaltstypen einschränken und nur die beliebtesten Anfragen in Ihren Cache legen.

Die Cache-Neuvalidierung ist eine Funktion, die kürzlich zu NGINX Open Source und NGINX Plus hinzugefügt wurde. Es ändert die If-Modified-Since -Funktion, sodass NGINX, wenn es einen zwischengespeicherten Wert aktualisieren muss, kein einfaches GET ausführt, um eine neue Version dieses Inhalts abzurufen; es führt ein bedingtes GET aus und sagt: „Ich habe eine zwischengespeicherte Version, die zu diesem bestimmten Zeitpunkt und Datum geändert wurde.“

Der Ursprungsserver hat die Möglichkeit zu antworten mit 304„ Nicht geändert“ bedeutet praktisch, dass die Version, die Sie haben, immer noch die aktuellste verfügbare Version ist. Dadurch wird Upstream-Bandbreite gespart, der Ursprungsserver muss unveränderte Inhalte nicht erneut senden und möglicherweise werden auch Festplattenschreibvorgänge eingespart. NGINX muss diesen Kontakt nicht auf die Festplatte streamen und ihn dann an die richtige Stelle verschieben, wodurch die alte Version überschrieben wird.

34:45 Kontrolle über die Cache-Zeit

Sie können genau steuern, wie lange Inhalte zwischengespeichert werden sollen. Sehr häufig stellt der Ursprungsserver Inhalte mit Cache-Headern bereit, die für die Browser geeignet sind – langfristiges Caching mit einer relativ häufigen Aufforderung zum Aktualisieren der Inhalte. Möglicherweise möchten Sie jedoch, dass der direkt vor Ihrem Ursprungsserver sitzende NGINX-Proxy die Dateien etwas häufiger aktualisiert, um Änderungen schneller zu übernehmen.

Wenn Sie das Cache-Timeout für die Browser von 60 Sekunden auf 10 Sekunden reduzieren, steigt die Last erheblich an. Wenn Sie das Cache-Timeout in NGINX von 60 Sekunden auf 10 Sekunden erhöhen, steigt die Last jedoch nur geringfügig an. Dadurch werden für jede Anfrage fünf weitere Anfragen pro Minute an Ihre Ursprungsserver gesendet, während bei den Remoteclients alles von der Anzahl der Clients abhängt, die mit ähnlichen Dingen auf Ihrer Site aktiv sind.

Sie können also die Logik und Absicht Ihres Ursprungsservers außer Kraft setzen. Sie können bestimmte Header maskieren oder NGINX anweisen, diese zu ignorieren: X-Accel-Expires , Cache-Control oder Expires . Und Sie können mit der Direktive proxy_cache_valid in Ihrer NGINX-Konfiguration eine Standard-Cache-Zeit angeben.

36:18 Zwischenspeichern / Nicht zwischenspeichern

Manchmal möchten Sie Inhalte nicht zwischenspeichern, die laut Ursprungsserver zwischenspeicherbar sind, oder Sie möchten sicherstellen, dass Sie die in NGINX gespeicherte Inhaltsversion umgehen. Die Anweisungen proxy_cache_bypass und proxy_no_cache geben Ihnen dieses Maß an Kontrolle.

Sie können sie als Abkürzung verwenden, um auszudrücken, dass Sie den Cache umgehen möchten, wenn ein bestimmter Satz von Anforderungsheadern festgelegt ist, etwa eine HTTP-Autorisierung, oder ein Anforderungsparameter vorhanden ist – entweder um den Cache in NGINX automatisch zu aktualisieren oder um ihn einfach vollständig zu überspringen und ihn immer vom Ursprungsserver abzurufen.

Normalerweise werden diese für relativ komplexe Caching-Entscheidungen durchgeführt, bei denen Sie detaillierte Entscheidungen über die Werte von Cookies und Autorisierungsheadern treffen, um zu steuern, was zwischengespeichert werden soll, was immer vom Ursprungsserver empfangen werden soll und was niemals im NGINX-Cache gespeichert werden soll.

37:25 Mehrere Caches

Schließlich möchten Sie bei Bereitstellungen in sehr großem Maßstab möglicherweise aus mehreren Gründen mehrere Caches innerhalb einer einzelnen NGINX-Instanz untersuchen. Je nach Art Ihrer Site und je nachdem, wie wichtig die Leistung dieser Site ist, können für verschiedene Mandanten auf Ihrem NGINX-Proxy unterschiedliche Cache-Richtlinien gelten. In einer Shared-Hosting-Situation können dies sogar von dem jeweiligen Plan abhängen, für den sich die einzelnen Mandanten angemeldet haben.

Oder Sie verfügen über mehrere Festplatten im NGINX-Host und es ist am effizientesten, auf jeder Festplatte einen individuellen Cache bereitzustellen. Die goldene Regel besteht darin, die Anzahl der Kopien von einer Festplatte auf eine andere zu minimieren. Dies können Sie erreichen, indem Sie jeder Festplatte einen Cache zuordnen und die temporäre Datei für jeden Proxy, der diesen Cache verwendet, auf der richtigen Festplatte fixieren.

Der Standardvorgang besteht darin, dass NGINX, wenn es Inhalte von einem Upstream-Proxy empfängt, diese auf die Festplatte streamt, sofern sie nicht klein genug sind und in den Speicher passen. Sobald der Inhalt auf die Festplatte gestreamt wurde, wird er in den Cache verschoben. Dieser Vorgang ist wesentlich effizienter, wenn der Speicherort im Cache für die temporären Dateien (die Festplatte, auf der die temporären Dateien gespeichert sind) derselbe ist wie die Festplatte, auf der der Cache gespeichert ist.

39:07 Kurzübersicht – Warum Cache?

Wir haben also über das Caching gesprochen, wir haben über die von NGINX verwendeten Methoden gesprochen, über die Implementierung innerhalb von NGINX und über Möglichkeiten, es zu optimieren. Da wir uns dem Ende nähern, wollen wir noch einmal kurz wiederholen, warum Sie Inhalte überhaupt zwischenspeichern möchten. NGINX wird auf 114 Millionen Websites weltweit eingesetzt und viele dieser Benutzer nutzen NGINX wegen seiner Webbeschleunigungs- und Inhaltscaching-Funktionen. [ Anm.: Diese Statistik galt zum Zeitpunkt des Webinars im Mai 2014. ]

39:44 Warum ist die Seitengeschwindigkeit wichtig?

Diese Funktionen verbessern die Geschwindigkeit einer Website – sie bieten Endbenutzern ein besseres Erlebnis – und die Geschwindigkeit von Webseiten ist wirklich, wirklich wichtig. Seit vielen Jahren beobachten Analysten das Benutzerverhalten und haben die sogenannte „N-Sekunden-Regel“ entwickelt. So lange ist ein durchschnittlicher Benutzer bereit, auf das Laden und Rendern einer Seite zu warten, bevor er gelangweilt und ungeduldig wird und zu einer anderen Website, beispielsweise der eines Konkurrenten, wechselt.

Da sich die Standards verbessert haben und die Erwartungen der Benutzer immer höher geworden sind, sinkt immer mehr die Zeit, die die Benutzer bereit sind zu warten. Mithilfe einer etwas zweifelhaften Mathematik könnte man dies extrapolieren und zu dem Schluss kommen, dass die Geduldsschwelle der Benutzer etwa im Jahr 2016 unter Null liegen wird.

40:46 Google hat die Regeln geändert

Doch tatsächlich hat uns die Technologie überholt. Google hat dies vor einigen Jahren bei der Einführung von Google Instant Search grafisch dargestellt. Wenn Sie bei Google jetzt einen Suchbegriff in ein Suchfeld eingeben, zeigt Ihnen Google die Suchergebnisse der Kandidaten an, noch bevor Sie mit der Eingabe fertig sind. Dies verdeutlicht den enormen Wandel der Erwartungen an das moderne Internet. Wie Google selbst sagte: „Benutzer erwarten heute, dass Webseiten auf die gleiche Weise reagieren wie das Umblättern der Seiten eines Buches“ – also genauso schnell, nahtlos und flüssig.

41:28 Die Kosten schlechter Leistung

Wenn Sie dieses Leistungsniveau nicht erreichen, kann dies erhebliche Auswirkungen auf die KPI haben, die Sie mit Ihrer Website oder Ihrem Webdienst verknüpfen. Ob es sich um Anzeigen-Klickraten handelt: Google selbst hat festgestellt, dass die Klickrate bei Anzeigen um 20 % sinkt, wenn das Laden der Suchseiten eine halbe Sekunde länger dauert. Ob es um Umsatz geht: In einem gezielten Versuch, die Auswirkungen langsamer Webseiten zu untersuchen, erhöhte Amazon die Seitenladezeit absichtlich in Vielfachen von 100 ms und stellte fest, dass der Umsatz der betroffenen Kunden pro 100 ms Erhöhung typischerweise um 1 % sank.

Viele andere Analysten, Websites und Ermittler berichteten von ähnlichen Auswirkungen auf die Kennzahlen einer Website, sei es Verweildauer auf der Seite, Absprungrate usw. Vor Kurzem hat Google damit begonnen, die Seitengeschwindigkeit bei der Berechnung des Seitenrangs in den Suchergebnissen zu berücksichtigen. Was zu zählen scheint, ist die Zeit bis zum ersten Byte. Je länger es dauert, das erste Byte einer Seite zu laden, desto stärker wird Ihr Seitenrang beeinträchtigt. Das Problem einer Website kann darin bestehen, dass sie gar nicht erst aufgerufen wird, weil sie in den Google-Suchergebnissen auf Seite drei, vier oder fünf erscheint.

43:00 NGINX Caching ermöglicht Ihnen

Mithilfe der Caching-Funktionen von NGINX können Sie das Endbenutzererlebnis verbessern, indem Sie die Zeit bis zum ersten Byte verkürzen und dafür sorgen, dass Webinhalte schneller und reaktionsfähiger werden.

Mit NGINX können Sie Ihre Web-Infrastruktur konsolidieren und vereinfachen. NGINX ist nicht nur ein eigenständiger Webcache. NGINX umfasst einen Web-Ursprungsserver, ein direktes Gateway zu APIs wie FastCGI und in NGINX Plus die Funktionen zum Erstellen eines hochentwickelten, unternehmenstauglichen Load Balancers und Application Delivery Controllers. Dadurch können Sie mehrere unterschiedliche Netzwerkkomponenten in Ihrer Web-Infrastruktur in einer einzigen Komponente – NGINX oder NGINX Plus – konsolidieren, was Ihnen zuverlässigere, einfacher zu debuggende und schnellere Lösungen bietet.

Mit NGINX können Sie die Serverkapazität erhöhen, indem Sie den Upstream-Servern sich wiederholende Aufgaben abnehmen. Tatsächlich ist es sogar bei Inhalten, die scheinbar nicht zwischengespeichert werden können (beispielsweise der Startseite einer Blogging-Site), sinnvoll, diese nur für eine Sekunde auf dem NGINX-Proxy zwischenzuspeichern.

Wenn hundert Benutzer in derselben Sekunde den gleichen Inhalt anfordern, reduziert NGINX dies auf eine einzige Anforderung an den Ursprungsserver und stellt diesen Benutzern den Inhalt aus seinem Cache zurück mit der Zusicherung, dass dieser Inhalt nie mehr als eine Sekunde veraltet ist. Das ist für eine Blog-Site oder eine ähnliche Website oft mehr als ausreichend, macht aber hinsichtlich der Leistung einen gewaltigen Unterschied – sowohl hinsichtlich der Belastung der Upstream-Server als auch hinsichtlich des Aufwands, der für die Verwaltung und Bereitstellung ausreichender Kapazität entsteht.

Vergessen Sie nicht einen der strategischen Einsatzmöglichkeiten von NGINX: Sie sind durch die „Use Stale“-Funktion des Proxy-Cache vor Ausfällen von Upstream-Servern zu schützen. Wenn sie langsam laufen, wenn sie Fehler zurückgeben oder wenn irgendein Fehler auftritt, kann NGINX auf die lokal zwischengespeicherte Version des Inhalts zurückgreifen und diese weiter verwenden, bis Ihre Upstream-Server wiederhergestellt sind.

45:21 Abschließende Gedanken

38 % der weltweit am häufigsten genutzten Websites verwenden NGINX vor allem wegen seiner Funktionen zur Webbeschleunigung und Inhaltszwischenspeicherung. [ Anm.: Diese Statistik galt zum Zeitpunkt des Webinars im Mai 2014; den aktuellen Wert finden Sie hier . ] Weitere Lösungen und Einzelheiten finden Sie in den Blogs und Feature Briefs auf nginx.com , wo die Funktionen von NGINX und NGINX Plus beschrieben werden. Und werfen Sie einen Blick auf unsere Webinarliste . Dort finden Sie nicht nur zukünftige Webinare, sondern auch demnächst hinzugefügte Webinare aus vergangenen Veranstaltungen dieser Reihe.

Wenn Sie diese Funktionen genauer untersuchen möchten, stehen Ihnen natürlich die Dokumentationen und Lösungen unter nginx.org und nginx.com zur Verfügung. Nichts ist jedoch besser, als es herunterzuladen und auszuprobieren. Das Open-Source-Produkt finden Sie unter nginx.org , das kommerzielle, unterstützte Produkt mit zusätzlichen Funktionen für Lastenausgleich, Anwendungsbereitstellung, Verwaltung und Benutzerfreundlichkeit unter nginx.com .

Also Leute, vielen Dank für Ihre Zeit und Ihre Aufmerksamkeit. Ich hoffe, dass diese Präsentation und der Überblick über das Inhalts-Caching in NGINX für viele von Ihnen nützlich und aufschlussreich waren.

Fragen und Antworten

Beginnen wir mit der Bearbeitung der Fragen und schauen wir, wie wir abschneiden.

47:20 Byte-Range-Anfragen

Wir haben eine Frage zu Byte-Bereichsanforderungen. Byte-Bereichsanforderungen werden verwendet, wenn ein Client einen Teil des Inhalts anfordert, aber nur eine Teilmenge dieses Inhalts benötigt. Angenommen, es handelt sich um eine Videodatei und der Client benötigt nur einen Teil des Videos. Oder, was sehr häufig vorkommt, ist eine PDF-Datei: Der Benutzer hat die Kopfzeilen mit Index in der PDF-Datei gelesen und der Client möchte nur einen bestimmten Satz von Seiten herunterladen. Wie funktioniert das im Inhaltscache von NGINX?

Der Ablauf ist wie folgt. Wenn NGINX eine Bytebereichsanforderung für eine Ressource empfängt und sich die gesamte Ressource bereits im Cache befindet, antwortet NGINX aus dem Cache mit dem vom Client angeforderten Bytebereich. Wenn sich diese Ressource nicht im Cache befindet, fordert NGINX die gesamte Ressource vom Upstream-Server an und speichert diese Ressource im Cache. Derzeit befolgt NGINX an diesem Punkt die Bytebereichsanforderung nicht und gibt die gesamte Ressource an den Client zurück. In den meisten Situationen ist das ein akzeptables Verhalten.

Wenn ein Client beispielsweise ein PDF-Dokument herunterlädt, wird seine erste Anforderung ohnehin das gesamte Dokument betreffen. Erst wenn dieses Dokument gestreamt wird, bricht der Client die Verbindung ab und beginnt, Byte-Bereichsanforderungen zu stellen. Für zwischengespeicherte Inhalte berücksichtigt NGINX daher Byte-Bereichsanforderungen. Bei nicht zwischengespeicherten Inhalten ruft NGINX den gesamten Inhalt vom Upstream-Server ab und gibt den gesamten Inhalt in dieser einen Instanz an den Client zurück.

49:13 Proxy-Cache erneut validieren

Dies ist eine Frage zur erneuten Validierungsfunktion des Proxy-Cache. Mit dieser Funktion kann NGINX einen bedingten GET-Befehl an den Upstream-Server senden, um zu prüfen, ob sich der Inhalt geändert hat. Die Frage ist:

Werden bei der erneuten Validierung des Proxy-Cache ETags berücksichtigt oder nur das „If-Modified-Since“ -Datum des Inhalts?

Die Antwort lautet, dass lediglich das „If-Modified-Since “-Datum des Inhalts geprüft wird. Aus praktischen Gründen empfiehlt es sich, in Ihren Antworten immer „If-Modified-Since“ einzuschließen und ETags als optional zu behandeln, da sie nicht so einheitlich oder umfassend behandelt werden wie das „Letzte Änderungsdatum“, das Sie in Ihren Antworten behandeln.

50:07 Den Cache auf gleich viele Festplatten verteilen

Ist es für NGINX möglich, die Caching-Last für eine einzelne Site auf einige gleiche Festplatten zu verteilen, um eine optimale Leistung zu erzielen?

Ja, das ist es. Es erfordert ein wenig Arbeit. Das typische Szenario besteht darin, eine Reihe von Festplatten ohne RAID einzusetzen und dann einzelne Caches bereitzustellen, von denen jeder Festplatte zugeordnet ist. Es sind einige zusätzliche Konfigurationen und eine Partitionierung des Datenverkehrs erforderlich. Wenn Sie Hilfe bei der Konfiguration benötigen, wenden Sie sich entweder an unsere Community und wir werden uns dort um Ihr spezielles Anliegen kümmern. Wenn Sie NGINX Plus verwenden, wenden Sie sich an unser Supportteam und wir helfen Ihnen gerne weiter.

50:50 Vary -Kopfball

Berücksichtigt NGINX den Vary- Header beim Cache-Treffer und -Fehler?

Nein, NGINX verarbeitet Vary -Header nicht automatisch. Wenn dies ein Problem darstellt, können Sie den Vary -Header einfach zum Proxy-Cache-Schlüssel hinzufügen, sodass der eindeutige Schlüssel, der zum Speichern der Antwort verwendet wird, den Wert des Vary -Headers enthält. Dann können Sie mehrere unterschiedliche Versionen speichern.

51:25 Zwischenspeichern von Primitiven

Werden alle Caching-Grundelemente und -Direktiven beachtet?

Im Allgemeinen ja. Es gibt einige Randfälle wie Vary -Header, die nicht berücksichtigt werden. In vielen Fällen besteht ein gewisser Spielraum bei der Interpretation der RFC-Anforderungen durch die verschiedenen Caches. Wo möglich, haben wir uns für Implementierungen entschieden, die zuverlässig, konsistent und einfach zu konfigurieren sind.

51:52 Upstream-Header und Daten

Werden sowohl Upstream-Header als auch -Daten zwischengespeichert?

Ja, sie sind. Wenn Sie eine Antwort aus dem Cache erhalten, werden sowohl die Header als auch der Antworttext zwischengespeichert.

52:13 *-Kodierungsheader

Die Header-Werte werden ebenso wie der Antworttext zwischengespeichert, daher … wäre ich ziemlich erstaunt, wenn NGINX mit den verschiedenen Kombinationen von Transfer-Encoding nicht ordnungsgemäß funktionieren würde. Accept-Encoding wird häufig über einen Vary -Header implementiert. Daher gelten die früheren Kommentare zur Notwendigkeit, Vary -Header in Ihren Cache-Schlüssel einzufügen, auch hier (bei Clients, die dies nicht unterstützen).

52:56 SPDY

Funktioniert das Caching für SPDY?

Absolut. Sie können es sich als Frontend-Proxy für NGINX vorstellen, obwohl es in der Praxis sehr, sehr tief in den NGINX-Kernel eingebunden ist. Ja, SPDY funktioniert zum Zwischenspeichern.

53:15 Vary Header, Runde 2

Hier ist eine weitere Frage zum Vary -Header. Um dies zu bestätigen: Wenn Sie Vary -Header-Antworten und Gzips verwenden, sehen Sie sich einige der Diskussionen auf Trac oder auf unserer Community-Site an, um Lösungen hierfür zu finden. Der gängigste Ansatz besteht darin, den Vary -Header in den Cache-Schlüssel einzubetten.

53:45 PageSpeed

Q: Verwendet PageSpeed NGINX-Caching oder einen eigenen Caching-Mechanismus?

Das ist eine Frage, die Sie den PageSpeed-Entwicklern stellen müssen.

54:00 Andere Caches

Q: Wie schneiden andere Inhaltscaches im Vergleich zu NGINX ab?

CDNs sind sehr effektive Lösungen zum Zwischenspeichern von Inhalten. CDNs werden als Dienst bereitgestellt. Sie haben zwar eine eingeschränktere Kontrolle darüber, wie Inhalte zwischengespeichert werden und wie sie darin ablaufen, aber sie sind ein sehr effektives Tool, um Inhalte näher an die Endbenutzer heranzubringen. NGINX ist ein sehr effektives Tool zur Beschleunigung von Webanwendungen und sehr häufig werden beide zusammen eingesetzt. Bei Standalone-Caches wie Varnish gilt wiederum: Es handelt sich um sehr leistungsfähige Technologien, die in vielen Punkten ähnlich wie NGINX funktionieren. Einer der Vorteile von NGINX besteht darin, dass es Ursprungs-Anwendungs-Gateways, Caching und Lastenausgleich in einer einzigen Lösung zusammenführt. Dadurch erhalten Sie eine einfachere, konsolidiertere Infrastruktur, die sich leichter einführen, verwalten und debuggen lässt und bei Problemen leichter diagnostiziert werden kann.

Um das Webinar anzusehen, auf dem dieser Beitrag basiert, können Sie hier darauf zugreifen.

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.