Hochleistungs-Caching mit NGINX und NGINX Plus

Owen GarrettSenior Director, Produktmanagement

Inhaltsverzeichnis

Einleitung

0:00 Einführung1:22 Über dieses Webinar2:17 Grundprinzipien des Content-Cachings2:35 Grundprinzipien3:59 Funktionsweise des HTTP-Cachings7:46 Was speichert NGINX im Cache?

Content-Caching und NGINX

9:55 NGINX im Betrieb10:06 NGINX-Konfiguration11:14 Caching-Prozess15:32 Caching ist nicht nur für HTTP geeignet17:10 So verstehen Sie, was vor sich geht17:38 Cache-Instrumentierung19:08 Cache-Instrumentierung (Fortsetzung)20:09 Cache-Status21:57 So funktioniert Content-Caching in NGINX22:40 Funktionsweise23:53 Wie werden zwischengespeicherte Inhalte gespeichert?26:36 Cache vom Datenträger laden28:07 Datenträger-Cache verwalten29:22 Inhalte vom Datenträger löschen

Caching steuern

31:27 Caching steuern32:30 Verzögertes Caching34:45 Cache-Dauer steuern36:18 Cachen / Nicht cachen37:25 Mehrere Caches39:07 Kurzer Rückblick – Warum cachen?39:44 Warum ist die Seitengeschwindigkeit wichtig?40:46 Google hat die Regeln geändert41:28 Die Kosten schlechter Performance43:00 Das ermöglicht Ihnen NGINX-Caching45:21 Abschließende Gedanken

Fragen und Antworten

47:20 Byte-Range-Anfragen49:13 Revalidierung des Proxy-Caches50:07 Verteilung des Caches auf gleich große Festplatten50:50 Vary-Header51:25 Caching-Grundelemente51:52 Upstream-Header und -Daten52:13 *‑Encoding-Header52:56 SPDY53:15 Vary-Header, Runde 253:45 PageSpeed54:00 Andere Caches

0:00 Einführung

Andrew Alexeev: Willkommen zu unserem neuesten Webinar. Mein Name ist Andrew. NGINX wurde von Igor Sysoev mit dem Ziel entwickelt, Websites weltweit schneller und reaktionsfähiger zu machen und eine einfache Skalierung zu ermöglichen. Heute kommt NGINX bei über 30 % der führenden Websites und bei über 20 % aller Websites im Internet zum Einsatz. [Anmerkung der Redaktion: Diese Zahlen galten zum Zeitpunkt des Webinars im Mai 2014. Die aktuellen Werte finden Sie hier.] Ich hoffe, dass die Inhalte dieses Webinars für Sie hilfreich sind und sich auf Ihre bestehende oder geplante NGINX-Umgebung anwenden lassen.

Nun möchte ich Ihnen Owen Garrett vorstellen. Owen ist hier bei NGINX für die Produktentwicklung verantwortlich. Heute wird Owen darüber sprechen, wie Sie leistungsstarke Caching-Mechanismen in NGINX einsetzen können, um Ihre Anwendung davon zu entlasten, immer wieder dieselben Inhalte generieren zu müssen.

1:22 Über dieses Webinar

Owen Garrett: Vielen Dank, Andrew, und Ihnen allen herzlichen Dank, dass Sie sich in den nächsten 45 oder 50 Minuten Zeit für uns nehmen. Ich werde erläutern, wie NGINX im Hinblick auf Content-Caching funktioniert. Wir sehen uns einige Möglichkeiten zur Leistungssteigerung an und gehen etwas genauer darauf ein, wie Content-Caching tatsächlich funktioniert, damit Sie Probleme innerhalb von NGINX debuggen und diagnostizieren können. Abschließend gebe ich Ihnen einige clevere Hinweise und Tipps, mit denen Sie sehr präzise steuern können, wie NGINX mit cachefähigen Inhalten umgeht.

All dies dient denselben grundlegenden Zielen, die Andrew beschrieben hat: Ihren Upstream-Servern die Last abzunehmen, immer wieder dieselben Inhalte zu generieren, damit sie die Anwendungen ausführen können, die Ihr Unternehmen wirklich benötigt. Außerdem können Sie über die Kapazität dieser Server hinaus skalieren, Ihren Endnutzern eine bessere Servicequalität bieten und die Zuverlässigkeit Ihres Dienstes insgesamt erhöhen – selbst bei starken Lastspitzen aus dem Internet und möglichen Ausfällen von Upstream-Servern.

2:17 Grundprinzipien des Content-Cachings

Bevor wir uns mit der Implementierungskonfiguration von NGINX befassen, möchte ich kurz erläutern, wie das Caching von Inhalten grundsätzlich funktioniert, damit wir alle auf demselben Stand sind und von derselben Wissensgrundlage ausgehen.

2:35 Grundprinzipien

Das Grundprinzip des Content-Cachings besteht darin, die Upstream-Server von wiederkehrenden Aufgaben 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 grau dargestellten Upstream-Server auf der rechten Seite weitergeleitet.

Die Antwort wird an den entfernten Benutzer zurückgeleitet. Wenn sie jedoch zwischengespeichert werden kann (was das genau bedeutet, erläutern wir gleich), speichert NGINX eine Kopie dieser Antwort. Fordert ein anderer Benutzer – der orange dargestellte – denselben Inhalt an, kann NGINX ihn direkt aus seinem lokalen Cache bereitstellen, anstatt die Anfrage an den Upstream-Server weiterzuleiten.

Dieses Grundprinzip der Speicherung cachefähiger, unveränderlicher Inhalte wird von Ihrem Webbrowser, von einem CDN – die von Ihnen aufgerufenen Websites nutzen CDNs – und von NGINX auf anderen Geräten verwendet. NGINX fungiert dabei als Reverse-Proxy-Cache, der üblicherweise im Rechenzentrum oder in der Cloud in der Nähe der Ursprungsserver bereitgestellt wird, auf denen Ihre Webinhalte und Webanwendungen gehostet werden.

3:59 Funktionsweise des HTTP-Cachings

Der Ursprungsserver gibt mithilfe eines oder mehrerer allgemein bekannter und gut verständlicher HTTP-Antwortheader an, ob Inhalte zwischengespeichert werden können. Cache-Server können dieses Verhalten natürlich ignorieren, außer Kraft setzen oder ändern. Um die konfigurierte Zwischenspeicherung von Inhalten zu verstehen, müssen Sie jedoch zunächst genau wissen, wie ein Ursprungsserver angibt, dass Inhalte zwischengespeichert werden können, unverändert bleiben und die [zwischengespeicherte] Kopie eine bestimmte Gültigkeitsdauer hat.

Das Caching von Inhalten begann mit einem einfachen HTTP-Antwort-Header namens Expires. Der Ursprungsserver stellte Inhalte bereit und erklärte, dass diese bis zu dem im Expires-Header angegebenen Datum gültig seien. Diese Methode wurde jedoch schnell durch eine effektivere und flexiblere Methode ersetzt – den Cache-Control-Header.

Expires ist etwas umständlich und ineffizient. Datumsangaben müssen korrekt formatiert und geparst werden, während Cache-Control wesentlich schlanker und besser auf die Anforderungen und die Geschwindigkeit von Inhalts-Caches abgestimmt ist. Cache-Control deklariert Inhalte entweder als öffentlich oder privat und gibt bei öffentlichen Inhalten ein max-age an – die Anzahl der Sekunden, für die der Inhalt zwischengespeichert werden kann, bevor das Cache-Objekt ihn erneut anfordern muss.

Der dritte Header, der das Caching direkt steuert, ist X-Accel-Expires. Dieser Header ist NGINX-spezifisch und wird nur von NGINX verstanden. Er kommt zum Einsatz, wenn Sie das Verhalten der oben genannten Header außer Kraft setzen und NGINX direkt vorgeben möchten, wie lange ein Inhalt im Cache gespeichert werden soll.

In manchen Situationen soll der Webbrowser Inhalte über einen langen Zeitraum zwischenspeichern, während der Proxy-Cache (NGINX vor dem Ursprungsserver) sie nur für einen kürzeren Zeitraum vorhalten soll. So werden Änderungen schneller übernommen und an neue Clients ausgeliefert, während ältere Clients die Inhalte nicht unnötig erneut anfordern.

Diese Methode kann jedoch auch mithilfe der letzten beiden Header umgesetzt werden. Ein Ursprungsserver kann angeben, wann ein Inhalt zuletzt geändert wurde, und einen sogenannten ETag (Entity-Tag) deklarieren – eine nicht interpretierbare Zeichenfolge, häufig ein Hashwert, die diesen Inhalt identifiziert.

Clients können dann Anfragen mit bedingten GETs stellen. Sie können ihrer Anfrage einen If-Modified-Since- oder If-None-Match-Header hinzufügen. Damit gibt der Client an, dass er über eine zwischengespeicherte Version des Inhalts verfügt, die zuletzt zu einem bestimmten Zeitpunkt geändert wurde oder einen bestimmten ETag besitzt. Wenn die neueste auf dem Server vorhandene Version mit der Version des Clients übereinstimmt, antwortet der Server lediglich mit 304 Not Modified. Dies ist eine schnelle Antwort, die Netzwerkbandbreite spart und es dem Client ermöglicht, bei Bedarf zu prüfen, ob die zwischengespeicherte Kopie des Inhalts noch gültig ist.

Diese fünf Header legen aus Sicht eines Ursprungsservers fest, wie Inhalte zwischengespeichert werden können – ihre Gültigkeit, ihre Aktualität und im Hinblick auf den ETag, die Details des Inhalts selbst.

7:46 Was speichert NGINX im Cache?

Proxy-Caches wie NGINX können relativ frei auslegen, wie strikt sie diese Header befolgen. Natürlich sollten sie nichts zwischenspeichern, was nicht cachefähig ist, sie sind jedoch keineswegs verpflichtet, etwas zwischenzuspeichern, nur weil der Ursprungsserver angibt, dass es cachefähig ist.

Das grundlegende Verhalten von NGINX besteht darin, alle GET- und HEAD-Anfragen zwischenzuspeichern, die vom Ursprungsserver als cachefähig gekennzeichnet werden, sofern die Antwort keine Set-Cookie-Header enthält. Der Grund dafür ist, dass Set-Cookie-Header in der Regel eindeutige, anfragespezifische Daten enthalten und es daher standardmäßig nicht sinnvoll wäre, diesen Wert zwischenzuspeichern.

NGINX speichert jede Ressource unter einem bestimmten Schlüssel – einem Cache-Schlüssel. Alle Anfragen, die denselben Cache-Schlüssel erzeugen, werden mit derselben Ressource beantwortet. Standardmäßig wird der Cache der unverarbeiteten 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 ihrer Priorität) durch den X-Accel-Expires-Header, sofern vorhanden, andernfalls durch den Cache-Control-Header oder den veralteten Expires-Header festgelegt.

Sie können NGINX so konfigurieren, dass bestimmte dieser Header ignoriert werden oder stattdessen eine feste Cache-Dauer verwendet wird, völlig unabhängig von den Vorgaben des Ursprungsservers. Zum Nachschlagen: RFC 2616 definiert das gewünschte Verhalten eines Proxy-Caches in Bezug auf HTTP.

Damit erhalten Sie einen kurzen Eindruck von der universellen Einsetzbarkeit des Cachings und vom grundlegenden Standardverhalten von NGINX beim Zwischenspeichern von Inhalten, die in der Regel gefahrlos im Cache abgelegt werden können, um Ihre Website zu beschleunigen und Ihre Ursprungsserver zu entlasten.

9:55 NGINX im Betrieb

Sehen wir uns nun kurz NGINX im Betrieb an. NGINX lässt sich wirklich sehr einfach so konfigurieren, dass Inhalte zwischengespeichert werden.

10:06 NGINX-Konfiguration

Es sind nur ein paar Zeilen in Ihrer NGINX-Konfigurationsdatei: Mit der ersten wird ein Cache auf der Festplatte erstellt. Dabei legen bestimmte Parameter fest, wie die Dateien angeordnet werden, wann [Objekte in diesem Cache] ablaufen und wie groß der Cache ist. Die zweite, die Direktive proxy_cache, wird einem NGINX-Proxy zugeordnet und weist ihn an, die Inhalte (Ergebnisse, Antworten) in einem benannten Cache zwischenzuspeichern.

Hier habe ich also einen Cache namens one erstellt. Er belegt im Arbeitsspeicher 10 MB für Metadaten, während der Speicherplatz auf der Festplatte für zwischengespeicherte Inhalte unbegrenzt ist. Inhalte werden im Cache gespeichert und entfernt, wenn sie 60 Minuten lang inaktiv waren. Dieser Cache namens one wird von unserem Standardserver verwendet. Diese beiden [Direktiven], proxy_cache_path und proxy_cache, reichen aus, um zuverlässiges, konsistentes Caching für einen Proxyserver in NGINX zu ermöglichen.

11:14 Caching-Prozess

Der Prozess, den NGINX beim Empfang einer Anfrage und der Abfrage eines Caches durchläuft, sieht folgendermaßen aus: Zunächst lesen wir eine Anfrage ein (Kasten oben links auf dieser Folie) und erstellen aus dem unverarbeiteten URI und den weiteren Parametern den Cache-Schlüssel, anhand dessen wir die zu dieser Anfrage gehörende Ressource identifizieren. Anschließend überprüfen wir den Cache auf dem Datenträger, indem wir auf die Metadaten im Arbeitsspeicher zugreifen, um festzustellen, ob eine gültige, aktuelle Kopie der Antwort auf diese Anfrage vorhanden ist.

Wenn dies der Fall ist, gilt das als Cache-Treffer. NGINX kann die Anfrage dann direkt aus dem Cache beantworten. Dazu stellt NGINX die Inhalte vom Datenträger genauso bereit wie statische Inhalte. So profitieren Sie von der Leistung, Zuverlässigkeit und Skalierbarkeit, für die NGINX ausgelegt ist. Beim Bereitstellen von Inhalten aus dem Content-Cache von NGINX erhalten Sie genau dasselbe Leistungsniveau wie bei statischen Inhalten.

Andererseits kann es bei der Überprüfung des Caches zu einem Cache-Fehltreffer kommen. Das bedeutet, dass sich der Inhalt nicht im Cache befindet oder dass der Inhalt im Cache veraltet ist und aktualisiert werden muss. Im einfachsten Fall bedeutet ein solcher Fehltreffer, dass wir den Inhalt vom Ursprungsserver anfordern, die Antwort empfangen und prüfen, ob sie zwischengespeichert werden kann.

Wenn dies der Fall ist, streamen wir die Antwort auf die Festplatte, so wie NGINX es bei jeder großen, im Proxy-Modus verarbeiteten Antwort tut. Sobald sie [die Antwort] auf die Festplatte gestreamt wurde, kopieren wir sie in den Cache und liefern sie direkt aus dem Cache aus. Eine Herausforderung bei diesem Ansatz entsteht, wenn NGINX gleichzeitig mehrere Anfragen für denselben Inhalt erhält und diese alle zu einem Cache Miss führen.

Normalerweise würde NGINX all diese Anfragen an den Ursprungsserver weiterleiten und ihn dadurch möglicherweise überlasten – insbesondere bei Anfragen, deren Beantwortung viel Zeit in Anspruch nimmt. Aus diesem Grund können Sie eine Cache-Sperre verwenden. Die Direktive „proxy_cache_lock“ stellt sicher, dass beim Aktualisieren eines Inhalts jeweils nur eine Anfrage an den Upstream-Server gesendet wird.

In dem von mir beschriebenen Szenario würde also die erste Anfrage an den Upstream-Server gesendet, während die übrigen Anfragen nach demselben Inhalt zurückgehalten werden, bis entweder die Antwort bereitgestellt und in den Cache aufgenommen wurde (sodass dann alle Anfragen bedient werden können) oder ein Timeout eintritt [festgelegt durch die proxy_cache_lock_timeout-Direktive] – NGINX hat lange genug auf die Rückmeldung des Servers gewartet; zu diesem Zeitpunkt werden die zurückgehaltenen Anfragen an den Ursprungsserver weitergeleitet.

Mit proxy_cache_lock und dem Timeout verfügen Sie also über leistungsstarke Steuerungsmöglichkeiten. So können Sie sicherstellen, dass bei einer stark frequentierten Website mit vielen Anfragen nach demselben Inhalt der Ursprungsserver nicht plötzlich durch mehrere Anfragen überlastet wird, wenn dieser Inhalt im Cache abläuft.

Beim Caching-Prozess in NGINX gibt es noch ein weiteres Element, das sich nicht ohne Weiteres in dieses Flussdiagramm einordnen lässt, da es nahezu jede Phase des Diagramms betrifft. Dabei handelt es sich um die mit der Direktive proxy_cache_use_stale konfigurierte Funktion. Wenn eine dieser Phasen aus irgendeinem Grund fehlschlägt – etwa weil beim Aktualisieren des Inhalts eine Zeitüberschreitung auftritt, der Upstream-Server eine fehlerhafte Antwort liefert oder ein anderer Fehler auftritt –, können wir jederzeit direkt aus dem Cache antworten, selbst wenn der dort gespeicherte Inhalt veraltet ist.

Dies ist ein äußerst leistungsfähiges Werkzeug für den Fall, dass Ihre Upstream-Server durch zu viel Datenverkehr überlastet sind oder aufgrund von Wartungsarbeiten oder eines schwerwiegenden Fehlers ausfallen. Es stellt sicher, dass NGINX Ihre Inhalte weiterhin mithilfe der veralteten Inhalte aus dem Cache bereitstellen kann, anstatt eine Fehlermeldung an den Client zurückzugeben.

15:32 Caching ist nicht nur für HTTP geeignet

Caching in NGINX ist nicht nur auf HTTP beschränkt. NGINX ist weit mehr als nur ein HTTP-Proxy, der Anfragen an vorgelagerte Webserver weiterleitet. In der Regel dienen diese vorgelagerten Webserver als Schnittstelle zu APIs wie FastCGI oder SCGI. NGINX kann dies auch direkt als Proxy übernehmen, ganz ähnlich wie ein HTTP-Proxy.

NGINX kann seine Caching-Techniken für HTTP-Proxys, für FastCGI-Proxys, für uWSGI-Proxys und für SCGI-Proxys einsetzen. Sie funktionieren weitgehend wie der HTTP-Proxy: Die Caches werden auf der Festplatte gespeichert und Antworten direkt ausgeliefert, sodass Anfragen nicht an diese Upstream-Dienste weitergeleitet werden müssen.

NGINX kann auch mit einem memcached-Server kommunizieren. Dabei handelt es sich um einen etwas anderen Caching-Ansatz. In diesem Fall speichert NGINX die Inhalte nicht direkt, sondern verwendet memcached als Proxy und greift auf einen externen Agenten zurück, der die benötigten Inhalte in memcached bereitstellt. Auch dies kann ein nützliches Werkzeug sein, und bei Bedarf gibt es zahlreiche Möglichkeiten, memcached von einer externen Website aus mit Inhalten zu befüllen. Sie können dies also als eine Möglichkeit betrachten, einen Cache für NGINX vorab zu befüllen, wenn dies Ihren geschäftlichen Anforderungen entspricht.

17:10 So verstehen Sie, was vor sich geht

Caching kann sehr komplex werden, wenn Sie über eine große Infrastruktur mit mehreren Ebenen verfügen, von denen einige Inhalte zwischenspeichern und andere nicht, einige Inhalte generieren und andere nicht. Dann kann es eine echte Herausforderung sein, nachzuvollziehen, was vor sich geht und woher die Inhalte stammen, sowie auftretende Probleme zu diagnostizieren und zu beheben. Mit NGINX machen wir es Ihnen so einfach wie möglich.

17:38 Cache-Instrumentierung

Mithilfe ausgefeilter Instrumentierungsfunktionen können Sie die Instrumentierung dynamisch steuern und so nachverfolgen, woher Inhalte stammen, wo sie im Cache gespeichert sind und welchen Status sie dort haben.

Der erste Schritt ist die Variable $upstream_cache_status, die für jede von NGINX beantwortete Anfrage berechnet wird – unabhängig davon, ob die Antwort aus dem Cache stammt oder nicht. Den Wert dieser Variable fügen Sie Ihrer Antwort fortlaufend mithilfe der Direktive add_header hinzu. Üblicherweise geben wir diesen Wert in einem X-Cache-Status-Header in der Antwort zurück. Er kann einen von sieben verschiedenen Werten annehmen, die angeben, wie der betreffende Inhalt ausgeliefert wurde – etwa ob der Cache umgangen, der Inhalt erneut validiert oder ein Cache-Treffer erzielt wurde.

Dies ist der erste Schritt, um herauszufinden, woher Ihre Antworten stammen. Kommen sie aus dem lokalen NGINX-Cache oder von einem Upstream-Server? Diesen Antwort-Header können Sie auf verschiedene Arten überprüfen – über die Befehlszeile mit Tools wie curl oder, wie sehr häufig üblich, mithilfe interaktiver Debugger in Ihrem Webbrowser.

Natürlich möchten Sie diesen Wert möglicherweise nicht gegenüber all Ihren Endnutzern offenlegen. Sie sollten gezielt festlegen, wann Sie diesen Wert in den Antwort-Header einfügen.

19:08 Cache-Instrumentierung (Forts.)

Die Konfigurationssprache von NGINX bietet Ihnen die Flexibilität, gezielt vorzugehen. Dieses Beispiel zeigt nur eine von vielen Möglichkeiten, dies umzusetzen. Wir prüfen die Remote-Adresse. Wenn es sich dabei um localhost handelt, speichern wir $upstream_cache_status in einer temporären Variablen ($cache_status). Wenn wir schließlich eine Antwort zurückgeben, fügen wir die temporäre Variable in die Antwort ein.

Auf diese Weise wird der Wert der Variable nur bei Anfragen von ausgewählten IP-Adressen angezeigt: $upstream_cache_status. Darüber hinaus können Sie noch vieles mehr tun. In Kürze sehen wir uns an, wie Inhalte auf dem Datenträger gespeichert werden. Sie können den Schlüssel, mit dem der Speicherort auf dem Datenträger berechnet wird, in die Antwort aufnehmen. Sie können alle möglichen Parameter in die Antwort aufnehmen, um die Diagnose des Caches während des Betriebs zu erleichtern.

20:09 Cache-Status

NGINX Plus, unsere kommerzielle Version von NGINX, bietet eine Reihe zusätzlicher Funktionen, die Anwendungsfälle wie Caching unterstützen. NGINX Plus ist eine kommerziell unterstützte Version von NGINX, die von unserem Entwicklungsteam in Moskau erstellt und umfangreichen Regressionstests unterzogen wird, um einen ordnungsgemäßen Betrieb sicherzustellen.

NGINX Plus bietet außerdem eine Reihe von Funktionen für Unternehmen, die NGINX als Reverse-Proxy und Load-Balancer einsetzen möchten. Dazu gehören Funktionen für den Lastenausgleich, Zustandsprüfungen und erweitertes Video-Streaming. In diesem Zusammenhang stehen zudem Funktionen für erweiterte Statusinformationen, eine bessere Diagnose und die Visualisierung der Vorgänge in NGINX zur Verfügung.

[Redaktion – Die obige Folie und der folgende Absatz wurden aktualisiert und beziehen sich nun auf die NGINX Plus API, die das ursprünglich an dieser Stelle behandelte separate Statusmodul ersetzt und als veraltet kennzeichnet.]

Für eine Demo können Sie demo.nginx.com/dashboard.html aufrufen. Dort sehen Sie eine Webseite, auf der die von NGINX Plus über die NGINX Plus API veröffentlichten Statusdaten angezeigt werden. Wenn Sie den angegebenen curl-Befehl ausführen, sehen Sie die JSON-Rohdaten, die direkt aus der NGINX Plus-Binärdatei stammen (hier werden sie an das Dienstprogramm jq weitergeleitet, damit jedes Element in einer eigenen Zeile und hierarchisch eingerückt dargestellt wird).

In diesen JSON-Daten finden Sie Echtzeitinformationen zum Status der einzelnen Caches in Ihrer NGINX-Plus-Bereitstellung. Zusammen mit der Variable $upstream_cache_status und den anderen Möglichkeiten zur Überwachung des Caches erhalten Sie einen sehr guten Überblick darüber, wie NGINX Inhalte zwischenspeichert. Zudem können Sie einzelne Anfragen genauer untersuchen, um festzustellen, ob sie aus dem Cache bedient wurden und welchen Status sie aktuell im Cache haben.

21:57 Funktionsweise des Content-Cachings in NGINX

Nachdem wir uns nun angesehen haben, wie wir das Content-Caching von außen untersuchen können, betrachten wir es jetzt von innen. Wie funktioniert es innerhalb von NGINX? Wie bereits erwähnt, arbeitet der Content-Cache in NGINX weitgehend genauso wie die Verarbeitung von Dateien auf der Festplatte. Bei der Bereitstellung von Inhalten aus unserem Content-Cache profitieren Sie von derselben Leistung, derselben Zuverlässigkeit und denselben Betriebssystemoptimierungen wie bei der Bereitstellung statischer Inhalte – also von der Leistung, für die NGINX bekannt ist.

22:40 Funktionsweise

Der Inhaltscache wird dauerhaft auf der Festplatte gespeichert. In Zusammenarbeit mit dem Betriebssystem laden wir diesen Festplattencache in den Arbeitsspeicher und geben dem Seitencache des Betriebssystems Hinweise darauf, welche Inhalte im Arbeitsspeicher vorgehalten werden sollen. Dadurch können wir Inhalte bei Bedarf äußerst schnell aus dem Cache bereitstellen.

Die Metadaten des Caches, also Informationen darüber, welche Inhalte vorhanden sind und wann sie ablaufen, werden separat in einem von allen NGINX-Prozessen gemeinsam genutzten Speicherbereich abgelegt und befinden sich stets im Arbeitsspeicher. Dadurch kann NGINX den Cache äußerst schnell abfragen und durchsuchen. Erst wenn die Antwort abgerufen und an den Endbenutzer ausgeliefert werden muss, greift NGINX auf den Seitencache zu.

Wir sehen uns an, wie Inhalte im Cache gespeichert werden, wie dieser persistente Cache beim Start in leere NGINX-Worker-Prozesse geladen wird und welche Wartungsarbeiten NGINX automatisch am Cache durchführt. Abschließend betrachten wir, wie Sie in bestimmten Situationen Inhalte manuell aus dem Cache entfernen können.

23:53 Wie werden zwischengespeicherte Inhalte gespeichert?

Wie Sie sich erinnern, wird der Inhaltscache mit einer Direktive namens „proxy_cache_path“ deklariert. Diese Direktive legt mehrere Parameter fest: den Speicherort des Caches in Ihrem Dateisystem, den Namen des Caches, die Größe des Arbeitsspeichers für die Metadaten und die Größe des Caches auf dem Datenträger. In diesem Fall beträgt die Cache-Größe auf dem Datenträger 40 MB.

Um zu verstehen, wo die Inhalte gespeichert werden, muss man den Cache-Schlüssel kennen – die eindeutige Kennung, die NGINX jeder cachefähigen Ressource zuweist. Standardmäßig setzt sich diese Kennung aus den grundlegenden Parametern der Anfrage zusammen: dem Schema, dem Host-Header, dem URI und etwaigen Zeichenfolgenargumenten.

Sie können dies jedoch bei Bedarf erweitern, beispielsweise um Cookie-Werte, Authentifizierungsheader oder sogar Werte, die Sie zur Laufzeit berechnet haben. Vielleicht möchten Sie für Benutzer im Vereinigten Königreich andere Versionen speichern als für Benutzer in den USA. All dies ist durch die Konfiguration der proxy_cache_key-Direktive möglich.

Wenn NGINX eine Anfrage verarbeitet, berechnet es den proxy_cache_key und daraus anschließend eine MD5-Prüfsumme. Sie können dies mit dem weiter unten auf der Folie gezeigten Befehlszeilenbeispiel selbst nachvollziehen. Wir nehmen den Cache-Schlüssel httplocalhost:8002/time.php und übergeben ihn an md5sum. Achten Sie dabei darauf, über die Shell nicht zusätzlich einen Zeilenumbruch zu übergeben.

Dadurch wird der MD5-Hashwert berechnet, der diesem cachefähigen Inhalt entspricht. NGINX verwendet diesen Hashwert, um den Speicherort auf der Festplatte zu bestimmen, an dem der Inhalt abgelegt werden soll. In proxy_cache_path sehen Sie, dass wir einen zweistufigen Cache mit einem Verzeichnis aus einem Zeichen und anschließend einem Verzeichnis aus zwei Zeichen angeben. Wir entnehmen diese Zeichen am Ende der Zeichenfolge, um ein Verzeichnis namens 4 und ein Unterverzeichnis namens 9b zu erstellen. Anschließend speichern wir den Inhalt des Caches (zusammen mit den Headern und einigen wenigen Metadaten) in einer Datei auf der Festplatte.

Sie können das Caching von Inhalten testen. Sie können den Cache-Schlüssel als einen der Antwort-Header ausgeben und ihn durch md5sum leiten, um den zugehörigen Hash-Wert zu berechnen. Anschließend können Sie den Wert auf dem Datenträger und die von NGINX zwischengespeicherten Header überprüfen, um sicherzustellen, dass er tatsächlich vorhanden ist und um zu verstehen, wie all dies zusammenhängt.

26:36 Cache vom Datenträger laden

Da die Inhalte nun dauerhaft auf der Festplatte gespeichert sind, muss NGINX sie beim Start in den Arbeitsspeicher laden – genauer gesagt muss NGINX den Festplatten-Cache durchlaufen, die Metadaten extrahieren und diese anschließend in das von allen Worker-Prozessen verwendete Shared-Memory-Segment laden. Dies geschieht mithilfe eines Prozesses, der als Cache-Loader bezeichnet wird.

Beim Start wird einmalig ein Cache-Loader ausgeführt, der die Metadaten in kleinen Blöcken vom Datenträger lädt: jeweils 100 Dateien innerhalb eines Zeitfensters von 200 ms, gefolgt von einer Pause von 50 ms. Dieser Vorgang wird wiederholt, bis der gesamte Cache durchlaufen und das Shared-Memory-Segment gefüllt wurde.

Der Cache-Loader wird anschließend beendet und muss erst wieder ausgeführt werden, wenn NGINX neu gestartet oder neu konfiguriert wird und das Shared-Memory-Segment neu initialisiert werden muss. Sie können die Funktionsweise des Cache-Loaders optimieren, was bei sehr schnellen Festplatten und geringer Auslastung sinnvoll sein kann. Sie können ihn beschleunigen oder etwas drosseln, wenn Ihr Cache sehr viele Dateien enthält, Sie langsame Festplatten verwenden und verhindern möchten, dass der Cache-Loader beim Start von NGINX übermäßig viel CPU-Leistung beansprucht.

28:07 Verwalten des Festplatten-Caches

Sobald sich der Cache im Arbeitsspeicher befindet und Dateien auf der Festplatte gespeichert sind, besteht die Gefahr, dass zwischengespeicherte Dateien, auf die nie zugegriffen wird, für immer dort verbleiben. NGINX speichert sie beim ersten Zugriff. Wenn jedoch keine weiteren Anfragen für eine Datei eingehen, bleibt [die Datei] einfach auf der Festplatte liegen, bis sie irgendwann bereinigt wird.

Bei diesem Etwas handelt es sich um den Cache-Manager; er wird regelmäßig ausgeführt und entfernt Dateien von der Festplatte, auf die innerhalb eines bestimmten Zeitraums nicht zugegriffen wurde. Außerdem löscht er Dateien, wenn der Cache zu groß ist und seine festgelegte Größe überschritten hat. Dabei werden die am längsten nicht verwendeten Dateien zuerst gelöscht. Sie können diesen Vorgang ebenso wie den Cache-Loader mithilfe von Parametern der proxy_cache_path-Direktive konfigurieren:

• Die inactive-Zeit beträgt standardmäßig 10 Minuten.
• Für den Parameter „max-size“ gibt es standardmäßig keine Begrenzung. Wenn Sie für den Cache eine Begrenzung mit „max-size“ festlegen, kann diese zeitweise überschritten werden. Sobald der Cache-Manager ausgeführt wird, entfernt er jedoch die am längsten nicht verwendeten Dateien, bis der Cache wieder unter diesem Grenzwert liegt.

29:22 Inhalte vom Datenträger löschen

Schließlich kann es vorkommen, dass Sie Inhalte vom Datenträger löschen möchten. Sie möchten eine Datei finden und löschen. Das ist relativ einfach, wenn Sie die zuvor besprochenen Techniken kennen – etwa den Cache-Schlüssel mit md5sum zu verarbeiten – oder einfach eine rekursive Suche mit grep im gesamten Dateisystem durchzuführen, um die zu löschende Datei bzw. die zu löschenden Dateien zu finden.

Alternativ können Sie bei Verwendung von NGINX Plus die in diesem Produkt integrierte Funktion zum Leeren des Caches nutzen. Mit dieser Funktion können Sie einen bestimmten Parameter aus der Anfrage auswerten. In der Regel verwenden wir dazu eine Methode namens „PURGE“, um die Anfrage als Cache-Löschanfrage zu kennzeichnen.

Das Leeren des Caches übernimmt ein spezieller NGINX-Plus-Handler, der den URI prüft und alle Dateien aus dem Cache löscht, die diesem URI entsprechen. An den URI kann ein Sternchen angehängt werden, sodass er als Präfix verwendet wird. In diesem Fall verwenden wir die Cache-Löschfunktion, um sämtliche Dateien zu löschen, die über localhost an Port 8001 bereitgestellt werden. Natürlich könnten Sie auch Unterverzeichnisse angeben.

Unabhängig davon, welche Methode Sie verwenden, können Sie jederzeit völlig bedenkenlos Dateien aus dem Cache auf der Festplatte löschen oder sogar mit rm -rf das gesamte Cache-Verzeichnis entfernen. NGINX läuft dabei ohne Unterbrechung weiter und prüft weiterhin, ob die Dateien auf der Festplatte vorhanden sind. Fehlen sie, führt dies zu einem Cache-Fehler. NGINX ruft die Daten dann erneut vom Ursprungsserver ab und speichert sie wieder im Cache auf der Festplatte. Das Löschen einzelner Dateien aus dem Cache ist daher jederzeit sicher, zuverlässig und stabil.

31:27 Caching steuern

Wir haben uns also angesehen, wie Caching funktioniert und wie es in NGINX implementiert ist. Außerdem haben wir uns eingehend damit beschäftigt, wie NGINX Dateien auf der Festplatte speichert, um eine ähnlich hohe Leistung wie bei statischen Inhalten zu erzielen. Sehen wir uns nun an, wie wir Caching noch intelligenter einsetzen können.

Bei einfachen Websites können Sie das Caching aktivieren, und in der Regel erfüllt es genau seinen Zweck: Es sorgt dauerhaft für die gewünschte Leistung und das gewünschte Cache-Verhalten. Es gibt jedoch immer Optimierungsmöglichkeiten und häufig Situationen, in denen das Standardverhalten nicht Ihren Anforderungen entspricht.

Möglicherweise legen Ihre Ursprungsserver nicht die richtigen Antwort-Header fest, oder Sie möchten die dort vorgenommenen Einstellungen direkt in NGINX überschreiben. Es gibt unzählige Möglichkeiten, NGINX so zu konfigurieren, dass sich das Caching-Verhalten präzise abstimmen lässt.

32:30 Verzögertes Caching

Sie können das Caching verzögern. Dies ist häufig sinnvoll, wenn Sie über einen großen Bestand an Inhalten verfügen, von denen viele nur ein- oder zweimal pro Stunde oder Tag abgerufen werden. Wenn Sie beispielsweise eine Unternehmensbroschüre haben, die nur sehr wenige Personen lesen, lohnt es sich oft nicht, diese Inhalte im Cache zu speichern. Mit verzögertem Caching können Sie einen Schwellenwert festlegen. Eine zwischengespeicherte Version dieses Inhalts wird erst dann angelegt, wenn er eine bestimmte Anzahl von Malen angefordert wurde. Solange der Schwellenwert proxy_cache_min_uses nicht erreicht ist, wird keine Version im Cache gespeichert.

So können Sie genauer festlegen, welche Inhalte in Ihren Cache aufgenommen werden. Der Cache selbst ist eine begrenzte Ressource, deren Größe in der Regel durch den verfügbaren Arbeitsspeicher Ihres Servers beschränkt ist, da Sie sicherstellen möchten, dass der Cache möglichst vollständig im Arbeitsspeicher vorgehalten wird. Daher empfiehlt es sich häufig, bestimmte Arten von Inhalten einzuschränken und nur häufig abgerufene Inhalte in den Cache aufzunehmen.

Die Cache-Revalidierung ist eine Funktion, die kürzlich zu NGINX Open Source und NGINX Plus hinzugefügt wurde. Sie passt die Funktion If-Modified-Since so an, dass NGINX beim Aktualisieren eines zwischengespeicherten Werts nicht einfach eine GET-Anfrage sendet, um eine neue Version dieses Inhalts abzurufen, sondern eine bedingte GET-Anfrage mit der Angabe: „Ich habe eine zwischengespeicherte Version, die zu diesem Zeitpunkt und an diesem Datum geändert wurde.“

Der Ursprungsserver kann mit 304 Not Modified antworten und damit im Wesentlichen mitteilen, dass die vorhandene Version nach wie vor die aktuellste ist. Das spart Upstream-Bandbreite, da der Ursprungsserver unveränderte Inhalte nicht erneut senden muss. Außerdem lassen sich dadurch möglicherweise Schreibvorgänge auf dem Datenträger vermeiden. NGINX muss diese Inhalte nicht auf den Datenträger streamen und anschließend an die entsprechende Stelle verschieben, wobei die alte Version überschrieben würde.

34:45 Kontrolle über die Cache-Dauer

Sie können detailliert festlegen, wie lange Inhalte zwischengespeichert werden sollen. Häufig stellt der Ursprungsserver Inhalte mit Cache-Headern bereit, die für Browser geeignet sind – langfristige Zwischenspeicherung mit relativ häufigen Anfragen zur Aktualisierung der Inhalte. Möglicherweise möchten Sie jedoch, dass der NGINX-Proxy, der Ihrem Ursprungsserver direkt vorgeschaltet ist, Dateien etwas häufiger aktualisiert, damit Änderungen schneller übernommen werden.

Wenn Sie das Cache-Timeout für Browser von 60 Sekunden auf 10 Sekunden reduzieren, steigt die Last enorm. Wenn Sie hingegen das Cache-Timeout in NGINX von 60 Sekunden auf 10 Sekunden reduzieren, nimmt die Last nur geringfügig zu. Dadurch kommen pro Anfrage fünf weitere Anfragen pro Minute an Ihre Ursprungsserver hinzu, während die Last bei Remote-Clients davon abhängt, wie viele Clients ähnliche Inhalte auf Ihrer Website aktiv nutzen.

Sie können also die von Ihrem Ursprungsserver vorgegebene Logik und Absicht außer Kraft setzen. Sie können bestimmte Header ausblenden oder NGINX anweisen, sie zu ignorieren: X-Accel-Expires, Cache-Control oder Expires. Außerdem können Sie mit der Direktive proxy_cache_valid in Ihrer NGINX-Konfiguration eine standardmäßige Cache-Dauer festlegen.

36:18 Cachen / Nicht cachen

Manchmal möchten Sie Inhalte nicht zwischenspeichern, obwohl der Ursprungsserver sie als cachefähig kennzeichnet, oder Sie möchten sicherstellen, dass die in NGINX gespeicherte Version des Inhalts umgangen wird. Mit den Direktiven „proxy_cache_bypass“ und „proxy_no_cache“ haben Sie die dafür erforderliche Kontrolle.

Sie können diese Direktiven als Kurzform verwenden, um festzulegen, dass der Cache umgangen werden soll, wenn bestimmte Anfrage-Header gesetzt sind, etwa für die HTTP-Authentifizierung, oder wenn ein Anfrageparameter vorhanden ist. Dabei kann entweder der Cache in NGINX automatisch aktualisiert oder vollständig übersprungen und der Inhalt stets vom Ursprungsserver abgerufen werden.

Typischerweise werden diese für recht komplexe Cache-Entscheidungen verwendet, bei denen anhand der Werte von Cookies und Autorisierungs-Headern detailliert festgelegt wird, was zwischengespeichert werden soll, was immer vom Ursprungsserver abgerufen werden soll und was niemals im NGINX-Cache gespeichert werden darf.

37:25 Mehrere Caches

Bei sehr umfangreichen Bereitstellungen kann es schließlich aus mehreren Gründen sinnvoll sein, mehrere Caches innerhalb einer einzelnen NGINX-Instanz in Betracht zu ziehen. Für verschiedene Mandanten auf Ihrem NGINX-Proxy könnten unterschiedliche Cache-Richtlinien gelten – je nach Art Ihrer Website, der Bedeutung ihrer Performance oder sogar dem jeweiligen Tarif, den die einzelnen Mandanten bei einem Shared-Hosting-Angebot gebucht haben.

Oder Sie haben mehrere Festplatten auf dem NGINX-Host, und es ist am effizientesten, auf jeder Festplatte einen eigenen Cache einzurichten. Die goldene Regel lautet, die Anzahl der Kopiervorgänge von einer Festplatte auf eine andere zu minimieren. Dies erreichen Sie, indem Sie jeder Festplatte einen Cache fest zuweisen und die temporäre Datei für jeden Proxy, der diesen Cache verwendet, auf der entsprechenden Festplatte ablegen.

Standardmäßig schreibt NGINX Inhalte, die es von einem Upstream-Proxy empfängt, fortlaufend auf die Festplatte, sofern sie nicht klein genug sind, um in den Arbeitsspeicher zu passen. Nachdem die Inhalte auf die Festplatte geschrieben wurden, werden sie in den Cache verschoben. Dieser Vorgang ist wesentlich effizienter, wenn sich der Speicherort für die temporären Dateien (also die Festplatte, auf der sie gespeichert werden) auf derselben Festplatte befindet wie der Cache.

39:07 Kurzer Rückblick – Warum Caching?

Wir haben also über Caching gesprochen, über die von NGINX verwendeten Methoden, deren Implementierung in NGINX und darüber, wie Sie die Konfiguration optimieren können. Da wir uns nun dem Ende nähern, wollen wir noch einmal kurz zusammenfassen, warum Sie Inhalte überhaupt zwischenspeichern sollten. NGINX wird weltweit auf 114 Millionen Websites eingesetzt, und viele dieser Nutzer entscheiden sich aufgrund seiner Funktionen zur Webbeschleunigung und Inhaltszwischenspeicherung für NGINX. [Anmerkung der Redaktion – Diese Statistik war zum Zeitpunkt der Ausstrahlung des Webinars im Mai 2014 aktuell.]

39:44 Warum ist die Ladegeschwindigkeit einer Seite wichtig?

Diese Funktionen verbessern die Geschwindigkeit einer Website – sie sorgen für ein besseres Nutzererlebnis – und die Ladegeschwindigkeit von Webseiten ist wirklich äußerst wichtig. Seit vielen Jahren beobachten Analysten das Nutzerverhalten und leiten daraus die umgangssprachlich als „N-Sekunden-Regel“ bezeichnete Zeitspanne ab. Sie gibt an, wie lange ein durchschnittlicher Nutzer bereit ist, auf das Laden und Anzeigen einer Seite zu warten, bevor er sich langweilt, ungeduldig wird und zu einer anderen Website – etwa der eines Mitbewerbers – wechselt.

Mit der Verbesserung der Standards und den immer höheren Erwartungen der Nutzer wird die Zeitspanne, die sie zu warten bereit sind, immer kürzer. Mit etwas fragwürdiger Mathematik könnte man diese Entwicklung fortschreiben und zu dem Schluss kommen, dass Nutzer etwa ab 2016 ein negatives Maß an Geduld haben werden.

40:46 Google änderte die Regeln

Doch tatsächlich hat uns die Technologie überholt. Google veranschaulichte dies vor einigen Jahren eindrucksvoll mit der Einführung von Google Instant Search. Wenn man heute bei Google einen Suchbegriff in das Suchfeld eingibt, zeigt Google bereits mögliche Suchergebnisse an, noch bevor man die Eingabe beendet hat. Dies verdeutlicht, wie stark sich die Erwartungen an das moderne Internet gewandelt haben. Wie Google selbst erklärte, „erwarten Nutzer heute, dass Webseiten genauso reagieren wie das Umblättern einer Buchseite“ – ebenso schnell, nahtlos und flüssig.

41:28 Die Kosten schlechter Performance

Wenn Sie dieses Leistungsniveau nicht erreichen, kann sich das erheblich auf die KPIs auswirken, die Sie für Ihre Website oder Ihren Webdienst festgelegt haben. Das gilt etwa für die Klickrate von Anzeigen: Google selbst stellte fest, dass die Klickrate seiner Anzeigen um 20 % sank, wenn das Laden der Suchseiten eine halbe Sekunde länger dauerte. Gleiches gilt für den Umsatz: Um die Auswirkungen langsamer Webseiten gezielt zu untersuchen, erhöhte Amazon die Seitenladezeit bewusst in Schritten von 100 ms und stellte fest, dass der Umsatz mit den betroffenen Kunden in der Regel mit jeder Erhöhung um 100 ms um 1 % zurückging.

Viele andere Analysten, Websites und Forscher berichteten von ähnlichen Auswirkungen auf die Kennzahlen einer Website, etwa auf die Verweildauer, die Absprungrate usw. Seit einiger Zeit berücksichtigt Google bei der Ermittlung des Rankings in den Suchergebnissen auch die Ladegeschwindigkeit einer Seite. Entscheidend scheint dabei die Zeit bis zum ersten Byte zu sein. Je länger es dauert, bis beim Laden einer Seite das erste Byte empfangen wird, desto stärker wird ihr Ranking herabgestuft. Dadurch kann es passieren, dass eine Website gar nicht erst aufgerufen wird, weil sie erst auf der dritten, vierten oder fünften Seite der Google-Suchergebnisse erscheint.

43:00 Mit NGINX-Caching können Sie

Mit den Caching-Funktionen von NGINX können Sie die Benutzererfahrung verbessern, indem Sie die Zeit bis zum ersten Byte verkürzen und dafür sorgen, dass Webinhalte schneller und reaktionsfreudiger wirken.

Mit NGINX können Sie Ihre Webinfrastruktur konsolidieren und vereinfachen. NGINX ist nicht nur ein eigenständiger Webcache. NGINX umfasst einen Web-Origin-Server und ein direktes Gateway zu APIs wie FastCGI. NGINX Plus bietet darüber hinaus die Möglichkeit, einen hochentwickelten, unternehmenstauglichen Load Balancer und Application Delivery Controller aufzubauen. So können Sie mehrere unterschiedliche Netzwerkkomponenten Ihrer Webinfrastruktur in einer einzigen Komponente – NGINX oder NGINX Plus – zusammenführen und erhalten dadurch zuverlässigere, leichter zu debuggende und schnellere Lösungen.

Mit NGINX können Sie die Serverkapazität erhöhen, indem Sie den Upstream-Servern wiederkehrende Aufgaben abnehmen. Selbst bei Inhalten, die nicht zwischenspeicherbar erscheinen (beispielsweise die Startseite einer Blogging-Website), kann es sinnvoll sein, sie auch nur für eine Sekunde auf dem NGINX-Proxy zwischenzuspeichern.

Wenn hundert Benutzer innerhalb derselben Sekunde dieselben Inhalte anfordern, reduziert NGINX dies auf eine einzige Anfrage an den Ursprungsserver und stellt den Benutzern die Inhalte aus seinem Cache bereit. Dabei ist gewährleistet, dass die Inhalte nie mehr als eine Sekunde veraltet sind. Für einen Blog oder eine ähnliche Website ist das oft mehr als ausreichend und bewirkt dennoch einen enormen Leistungsunterschied – sowohl hinsichtlich der Auslastung der Upstream-Server als auch der Kosten für die Verwaltung und Bereitstellung ausreichender Kapazitäten.

Vergessen Sie schließlich nicht einen der strategischen Einsatzzwecke von NGINX: Sie mithilfe der „use stale“-Funktion des Proxy-Caches vor Ausfällen der Upstream-Server zu schützen. Wenn diese langsam laufen, Fehler zurückgeben oder eine andere Störung vorliegt, kann NGINX auf die lokal zwischengespeicherte Version des Inhalts zurückgreifen und diese so lange verwenden, bis Ihre Upstream-Server wieder verfügbar sind.

45:21 Abschließende Gedanken

38 % der meistbesuchten Websites weltweit nutzen NGINX vor allem wegen seiner Funktionen zur Webbeschleunigung und zum Zwischenspeichern von Inhalten. [Redaktion – Diese Statistik galt zum Zeitpunkt der Ausstrahlung des Webinars im Mai 2014; den aktuellen Wert finden Sie hier.] Weitere Lösungen und ausführlichere Informationen finden Sie in den Blogs und Funktionsübersichten auf nginx.com, in denen die Funktionen von NGINX und NGINX Plus erläutert werden. Werfen Sie auch einen Blick auf unsere Webinar-Liste, die nicht nur zukünftige Webinare enthält, sondern demnächst auch um Webinare vergangener Veranstaltungen dieser Reihe ergänzt wird.

Und wenn Sie diese Funktionen näher untersuchen möchten, finden Sie natürlich Dokumentationen und Lösungen unter nginx.org und nginx.com, aber nichts geht darüber, die Software herunterzuladen und selbst auszuprobieren. Das Open-Source-Produkt finden Sie unter nginx.org, das kommerzielle Produkt mit Support und zusätzlichen Funktionen für Lastverteilung, Anwendungsbereitstellung, Verwaltung und Benutzerfreundlichkeit hingegen unter nginx.com.

Vielen Dank für Ihre Zeit und Ihre Aufmerksamkeit. Ich hoffe, dass diese Präsentation und Einführung in das Content-Caching mit NGINX für viele von Ihnen hilfreich und aufschlussreich war.

Fragen und Antworten

Beginnen wir mit den Fragen und sehen wir, wie wir uns schlagen.

47:20 Byte-Range-Anfragen

Wir haben eine Frage zu Bytebereichsanfragen. Bytebereichsanfragen werden verwendet, wenn ein Client Inhalte anfordert, aber nur einen Teil davon benötigt. Nehmen wir an, es handelt sich um eine Videodatei und der Client benötigt nur einen Ausschnitt des Videos. Sehr häufig handelt es sich auch um eine PDF-Datei: Der Benutzer hat die Header gelesen, die einen Index der PDF-Datei enthalten, und der Client möchte nur bestimmte Seiten herunterladen. Wie funktioniert das im Inhaltscache von NGINX?

Der Vorgang läuft folgendermaßen ab: Wenn NGINX eine Bytebereichsanfrage für eine Ressource erhält und sich die gesamte Ressource bereits im Cache befindet, liefert NGINX den vom Client angeforderten Bytebereich aus dem Cache zurück. Befindet sich die Ressource nicht im Cache, fordert NGINX die gesamte Ressource vom Upstream-Server an und speichert sie im Cache. Derzeit berücksichtigt NGINX die Bytebereichsanfrage in diesem Fall nicht und sendet stattdessen die gesamte Ressource an den Client zurück. In den meisten Fällen ist dieses Verhalten akzeptabel.

Wenn ein Client beispielsweise ein PDF-Dokument herunterlädt, fordert er bei seiner ersten Anfrage ohnehin das gesamte Dokument an. Nur wenn dieses Dokument gestreamt wird, bricht der Client die Verbindung ab und beginnt, Bytebereichsanfragen zu stellen. Bei zwischengespeicherten Inhalten berücksichtigt NGINX also Bytebereichsanfragen. Bei nicht zwischengespeicherten Inhalten ruft NGINX den gesamten Inhalt vom Upstream-Server ab und sendet ihn in diesem einen Fall vollständig an den Client zurück.

49:13 Revalidierung des Proxy-Caches

Hier geht es um die Funktion zur Revalidierung des Proxy-Caches. Mit dieser Funktion kann NGINX eine bedingte GET-Anfrage an den Upstream-Server senden, um zu prüfen, ob sich der Inhalt geändert hat. Die Frage lautet:

Berücksichtigt die erneute Validierung des Proxy-Caches ETags oder nur das If-Modified-Since-Datum des Inhalts?

Die Antwort lautet, dass nur das If-Modified-Since-Datum des Inhalts geprüft wird. In der Praxis empfiehlt es sich daher, If-Modified-Since immer in Ihre Antworten aufzunehmen und ETags als optional zu betrachten, da sie nicht so einheitlich und weitverbreitet unterstützt werden wie das „Last-Modified“-Datum, das Sie in der Antwort angeben.

50:07 Verteilen des Caches auf gleich große Festplatten

Ist es möglich, dass NGINX die Cache-Daten einer einzelnen Website zur optimalen Leistung gleichmäßig auf mehrere gleichwertige Festplatten verteilt?

Ja, das ist möglich, erfordert jedoch etwas Aufwand. In einem typischen Szenario werden mehrere Festplatten ohne RAID eingesetzt und anschließend separate Caches eingerichtet, die jeweils einer Festplatte fest zugeordnet sind. Dafür sind zusätzliche Konfigurationsschritte und eine Aufteilung des Datenverkehrs erforderlich. Wenn Sie Unterstützung bei der Konfiguration benötigen, wenden Sie sich entweder an unsere Community, wo wir auf Ihre konkrete Anfrage eingehen, oder – falls Sie NGINX Plus verwenden – an unser Supportteam. Wir helfen Ihnen gerne weiter.

50:50 Vary-Header

Berücksichtigt NGINX den Vary-Header bei Cache-Treffern und -Fehlschlägen?

Nein, NGINX verarbeitet Vary-Header nicht automatisch. Falls dies ein Problem darstellt, lässt sich der Vary-Header einfach zum Proxy-Cache-Schlüssel hinzufügen, sodass der eindeutige Schlüssel, unter dem die Antwort gespeichert wird, den Wert des Vary-Headers enthält. Dadurch können mehrere unterschiedliche Versionen gespeichert werden.

51:25 Caching-Grundlagen

Werden alle Caching-Primitive und -Direktiven berücksichtigt?

Im Allgemeinen ja. Es gibt einige Sonderfälle, beispielsweise Vary-Header, die nicht berücksichtigt werden. In vielen Fällen besteht ein gewisser Spielraum bei der Auslegung der RFC-Anforderungen durch die verschiedenen Caches. Wo immer 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 die Upstream-Header als auch die Daten zwischengespeichert?

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

52:13 *‑Encoding-Header

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 korrekt funktionieren würde. Accept-Encoding wird häufig mithilfe eines Vary-Headers implementiert. Daher gelten hier die vorherigen Anmerkungen dazu, dass Vary-Header in den Cache-Schlüssel aufgenommen werden müssen (für Clients, die dies nicht unterstützen).

52:56 SPDY

Funktioniert Caching mit SPDY?

Auf jeden Fall. Man kann es sich als Frontend-Proxy für NGINX vorstellen, obwohl es in der Praxis sehr, sehr eng mit dem NGINX-Kernel verzahnt ist. Ja, SPDY unterstützt Caching.

53:15 Vary-Header, Runde 2

Hier ist eine weitere Frage zum Vary-Header. Zur Klarstellung: Wenn Sie Antworten mit Vary-Header und gzip-Komprimierung verwenden, sehen Sie sich einige der Diskussionen auf Trac oder auf unserer Community-Website an, um entsprechende Lösungen zu finden. Der gängigste Ansatz besteht darin, den Vary-Header in den Cache-Schlüssel einzubetten.

53:45 PageSpeed

F: Verwendet PageSpeed das NGINX-Caching oder einen eigenen Caching-Mechanismus?

Diese Frage müssten Sie den PageSpeed-Entwicklern stellen.

54:00 Andere Caches

F: Wie schneiden andere Content-Caches im Vergleich zu NGINX ab?

CDNs sind äußerst effektive Lösungen für das Caching von Inhalten. CDNs werden als Dienst bereitgestellt. Dadurch haben Sie weniger Kontrolle darüber, wie Inhalte zwischengespeichert werden und wann sie ablaufen. Dennoch sind sie ein äußerst effektives Werkzeug, um Inhalte näher an die Endnutzer zu bringen. NGINX ist ein sehr effektives Werkzeug zur Beschleunigung von Webanwendungen, und häufig werden beide gemeinsam eingesetzt. Auch eigenständige Caches wie Varnish sind äußerst leistungsfähige Technologien, die in vielerlei Hinsicht ähnlich wie NGINX funktionieren. Einer der Vorteile von NGINX besteht darin, dass es die Bereitstellung von Ursprungsinhalten, Anwendungs-Gateways, Caching und Lastverteilung in einer einzigen Lösung vereint. Dadurch erhalten Sie eine einfachere, stärker konsolidierte Infrastruktur, die sich leichter bereitstellen und verwalten lässt und bei Problemen eine einfachere Fehlersuche und Diagnose ermöglicht.

Das Webinar, auf dem dieser Beitrag basiert, können Sie hier ansehen.

Wenn Sie NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett