Ein Leitfaden zum Caching mit NGINX und NGINX Plus

Faisal MemonSoftwareentwickler

Wir alle wissen, dass die Performance von Anwendungen und Websites ein entscheidender Faktor für deren Erfolg ist. Wie Sie die Performance Ihrer Anwendung oder Website verbessern können, ist jedoch nicht immer klar. Die Qualität des Codes und der Infrastruktur ist natürlich entscheidend. In vielen Fällen können Sie die Benutzererfahrung Ihrer Anwendung jedoch erheblich verbessern, indem Sie sich auf einige grundlegende Techniken zur Anwendungsbereitstellung konzentrieren. Ein Beispiel dafür ist die Implementierung und Optimierung des Cachings in Ihrem Anwendungs-Stack. Dieser Blogbeitrag behandelt Techniken, mit denen sowohl Einsteiger als auch fortgeschrittene Benutzer durch die Nutzung der Content-Cache-Funktionen von NGINX und NGINX Plus eine bessere Performance erzielen können.

Überblick

Ein Inhaltscache befindet sich zwischen einem Client und einem „Ursprungsserver“ und speichert Kopien aller Inhalte, die er empfängt. Fordert ein Client Inhalte an, die im Cache gespeichert sind, gibt dieser die Inhalte direkt zurück, ohne den Ursprungsserver zu kontaktieren. Dies verbessert die Leistung, da sich der Inhaltscache näher am Client befindet, und ermöglicht eine effizientere Nutzung der Anwendungsserver, weil sie die Seiten nicht jedes Mal von Grund auf neu generieren müssen.

Zwischen dem Webbrowser und dem Anwendungsserver können sich mehrere Caches befinden: der Browser-Cache des Clients, zwischengeschaltete Caches, Content Delivery Networks (CDNs) sowie der Load Balancer oder Reverse Proxy vor den Anwendungsservern. Caching kann die Leistung erheblich verbessern, selbst auf der Ebene des Reverse Proxys bzw. Load Balancers.

Ein Beispiel: Letztes Jahr übernahm ich die Aufgabe, die Performance einer Website zu optimieren, die nur langsam geladen wurde. Als Erstes fiel mir auf, dass die Generierung der Startseite über 1 Sekunde dauerte. Nach einigem Debugging stellte ich fest, dass die Seite bei jeder Anfrage dynamisch generiert wurde, weil sie als nicht cachefähig gekennzeichnet war. Da sich die Seite selbst nicht sehr häufig änderte und nicht personalisiert war, war dies unnötig. Versuchsweise legte ich fest, dass die Startseite vom Load Balancer 5 Sekunden lang zwischengespeichert werden sollte. Allein dadurch verbesserte sich die Performance spürbar. Die Zeit bis zum ersten Byte sank auf wenige Millisekunden, und die Seite wurde sichtbar schneller geladen.

NGINX wird in einem Anwendungs-Stack häufig als Reverse-Proxy oder Load-Balancer eingesetzt und bietet umfassende Caching-Funktionen. Im nächsten Abschnitt wird erläutert, wie sich grundlegendes Caching mit NGINX konfigurieren lässt.

Grundlegendes Caching einrichten und konfigurieren

Zum Aktivieren des grundlegenden Cachings sind nur zwei Direktiven erforderlich: proxy_cache_path und proxy_cache. Die Direktive proxy_cache_path legt den Pfad und die Konfiguration des Caches fest, und die Direktive proxy_cache aktiviert ihn.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g                  inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

Die Parameter der proxy_cache_path-Direktive definieren die folgenden Einstellungen:

• Das lokale Verzeichnis für den Cache heißt „/path/to/cache/“.
• levels richtet unter /path/to/cache/ eine zweistufige Verzeichnishierarchie ein. Eine große Anzahl von Dateien in einem einzigen Verzeichnis kann den Dateizugriff verlangsamen. Daher empfehlen wir für die meisten Bereitstellungen eine zweistufige Verzeichnishierarchie. Wenn der Parameter levels nicht angegeben ist, legt NGINX alle Dateien im selben Verzeichnis ab.
• keys_zone richtet eine gemeinsam genutzte Speicherzone ein, in der Cache-Schlüssel und Metadaten wie Nutzungszeitgeber gespeichert werden. Da sich eine Kopie der Schlüssel im Arbeitsspeicher befindet, kann NGINX schnell feststellen, ob eine Anfrage ein HIT oder ein MISS ist, ohne auf den Datenträger zugreifen zu müssen. Dadurch wird die Prüfung erheblich beschleunigt. Eine 1‑MB-Zone kann Daten für etwa 8.000 Schlüssel speichern. Die im Beispiel konfigurierte 10‑MB-Zone kann somit Daten für etwa 80.000 Schlüssel speichern.
• max_size legt die Obergrenze für die Größe des Caches fest (in diesem Beispiel auf 10 Gigabyte). Diese Angabe ist optional. Wird kein Wert angegeben, kann der Cache so weit anwachsen, dass er den gesamten verfügbaren Speicherplatz belegt. Wenn die Cache-Größe den Grenzwert erreicht, entfernt ein als Cache-Manager bezeichneter Prozess die Dateien, die am längsten nicht verwendet wurden, um die Cache-Größe wieder unter den Grenzwert zu senken.
• inactive gibt an, wie lange ein Element im Cache verbleiben kann, ohne dass darauf zugegriffen wird. In diesem Beispiel wird eine Datei, die 60 Minuten lang nicht angefordert wurde, automatisch vom Cache-Manager-Prozess aus dem Cache gelöscht, unabhängig davon, ob sie abgelaufen ist oder nicht. Der Standardwert beträgt 10 Minuten (10m). Inaktive Inhalte unterscheiden sich von abgelaufenen Inhalten. NGINX löscht Inhalte nicht automatisch, wenn sie gemäß einem Cache-Control-Header abgelaufen sind (zum Beispiel Cache-Control:max-age=120). Abgelaufene (veraltete) Inhalte werden erst gelöscht, wenn während des mit inactive angegebenen Zeitraums nicht darauf zugegriffen wurde. Wenn auf abgelaufene Inhalte zugegriffen wird, aktualisiert NGINX sie vom Ursprungsserver und setzt den inactive-Timer zurück.
• NGINX schreibt Dateien, die für den Cache bestimmt sind, zunächst in einen temporären Speicherbereich. Die Direktive use_temp_path=off weist NGINX an, sie in dieselben Verzeichnisse zu schreiben, in denen sie zwischengespeichert werden. Wir empfehlen, diesen Parameter auf off zu setzen, um unnötiges Kopieren von Daten zwischen Dateisystemen zu vermeiden. use_temp_path wurde mit NGINX Version 1.7.10 und NGINX Plus R6 eingeführt.

Und schließlich aktiviert die Direktive „proxy_cache“ das Caching aller Inhalte, deren URL mit der des übergeordneten location-Blocks übereinstimmt (im Beispiel /). Sie können die Direktive „proxy_cache“ auch in einen server-Block aufnehmen; sie gilt dann für alle location-Blöcke des Servers, die keine eigene proxy_cache-Direktive enthalten.

Bereitstellung zwischengespeicherter Inhalte bei Ausfall des Ursprungsservers

Eine leistungsstarke Funktion des NGINX-Content-Cachings besteht darin, dass NGINX so konfiguriert werden kann, dass veraltete Inhalte aus seinem Cache bereitgestellt werden, wenn keine aktuellen Inhalte von den Ursprungsservern abgerufen werden können. Dies kann vorkommen, wenn alle Ursprungsserver für eine zwischengespeicherte Ressource ausgefallen oder vorübergehend ausgelastet sind. Anstatt den Fehler an den Client weiterzuleiten, stellt NGINX die veraltete Version der Datei aus seinem Cache bereit. Dies bietet eine zusätzliche Fehlertoleranz für die Server, für die NGINX als Proxy fungiert, und gewährleistet die Verfügbarkeit bei Serverausfällen oder Lastspitzen. Um diese Funktion zu aktivieren, fügen Sie die Direktive proxy_cache_use_stale hinzu:

location / {    # ...
    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
}

Bei dieser Beispielkonfiguration liefert NGINX, wenn es vom Ursprungsserver einen error, ein timeout oder einen der angegebenen 5xx-Fehler empfängt und sich eine veraltete Version der angeforderten Datei im Cache befindet, die veraltete Datei aus, anstatt den Fehler an den Client weiterzuleiten.

Feinabstimmung des Caches und Verbesserung der Leistung

NGINX bietet eine Vielzahl optionaler Einstellungen zur Feinabstimmung der Cache-Leistung. Das folgende Beispiel aktiviert einige davon:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g                  inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502
                              http_503 http_504;
        proxy_cache_background_update on;
        proxy_cache_lock on;

        proxy_pass http://my_upstream;
    }
}

Diese Direktiven konfigurieren das folgende Verhalten:

• proxy_cache_revalidate weist NGINX an, bedingte GET-Anfragen zu verwenden, wenn Inhalte von den Ursprungsservern aktualisiert werden. Wenn ein Client ein Element anfordert, das zwischengespeichert ist, aber gemäß den Cache-Control-Headern abgelaufen ist, fügt NGINX das Feld If-Modified-Since in den Header der GET-Anfrage ein, die an den Ursprungsserver gesendet wird. Dies spart Bandbreite, da der Server das vollständige Element nur sendet, wenn es seit dem im Header Last-Modified vermerkten Zeitpunkt geändert wurde, der an die Datei angehängt wurde, als NGINX sie ursprünglich zwischengespeichert hat.
• proxy_cache_min_uses legt fest, wie oft ein Element von Clients angefordert werden muss, bevor NGINX es im Cache speichert. Dies ist nützlich, wenn sich der Cache ständig füllt, da so sichergestellt wird, dass nur die am häufigsten aufgerufenen Elemente in den Cache aufgenommen werden. Standardmäßig ist proxy_cache_min_uses auf 1 gesetzt.
• Der Parameter „updating“ der Direktive „proxy_cache_use_stale“ weist NGINX in Verbindung mit der Aktivierung der Direktive „proxy_cache_background_update“ an, veraltete Inhalte auszuliefern, wenn Clients ein Element anfordern, das abgelaufen ist oder gerade vom Ursprungsserver aktualisiert wird. Alle Aktualisierungen werden im Hintergrund durchgeführt. Bis die aktualisierte Datei vollständig heruntergeladen wurde, wird bei allen Anfragen die veraltete Datei zurückgegeben.
• Wenn proxy_cache_lock aktiviert ist und mehrere Clients eine Datei anfordern, die sich nicht aktuell im Cache befindet (ein MISS) wird nur die erste dieser Anfragen an den Ursprungsserver weitergeleitet. Die übrigen Anfragen warten, bis diese Anfrage abgeschlossen ist, und rufen die Datei anschließend aus dem Cache ab. Ist proxy_cache_lock nicht aktiviert, werden alle Anfragen, die zu Cache-Fehltreffern führen, direkt an den Ursprungsserver weitergeleitet.

Cache auf mehrere Festplatten verteilen

Wenn Sie über mehrere Festplatten verfügen, können Sie den Cache mit NGINX auf diese verteilen. Das folgende Beispiel verteilt Clients anhand des Anfrage-URI gleichmäßig auf zwei Festplatten:

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m                 max_size=10g inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m
                 max_size=10g inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
              50%          “my_cache_hdd1”;
              50%          “my_cache_hdd2”;
}

server {
    # ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

Die beiden proxy_cache_path-Direktiven definieren zwei Caches (my_cache_hdd1 und my_cache_hdd2) auf zwei verschiedenen Festplatten. Der split_clients-Konfigurationsblock legt fest, dass die Ergebnisse der Hälfte der Anfragen (50%) in my_cache_hdd1 und die der anderen Hälfte in my_cache_hdd2 zwischengespeichert werden. Der auf der Variablen $request_uri (dem Anfrage-URI) basierende Hash bestimmt, welcher Cache für die jeweilige Anfrage verwendet wird. Dadurch werden Anfragen für einen bestimmten URI immer im selben Cache zwischengespeichert.

Beachten Sie, dass dieser Ansatz kein Ersatz für eine RAID-Festplattenkonfiguration ist. Bei einem Festplattenausfall kann es zu unvorhersehbarem Systemverhalten kommen. Unter anderem können Benutzer bei Anfragen, die an die ausgefallene Festplatte weitergeleitet wurden, den HTTP-Statuscode 500 erhalten. Eine ordnungsgemäße RAID-Festplattenkonfiguration kann Festplattenausfälle abfangen.

Häufig gestellte Fragen (FAQ)

In diesem Abschnitt werden einige häufig gestellte Fragen zum Content-Caching mit NGINX beantwortet.

Kann der NGINX-Cache instrumentiert werden?

Ja, mit der add_header-Direktive:

add_header X-Cache-Status $upstream_cache_status;

Dieses Beispiel fügt den Antworten an Clients einen X-Cache-Status-HTTP-Header hinzu. Für $upstream_cache_status sind folgende Werte möglich:

• MISS – Die Antwort wurde nicht im Cache gefunden und daher von einem Ursprungsserver abgerufen. Anschließend wurde die Antwort möglicherweise im Cache gespeichert.
• BYPASS – Die Antwort wurde vom Ursprungsserver abgerufen, anstatt aus dem Cache bereitgestellt zu werden, da die Anfrage einer proxy_cache_bypass-Direktive entsprach (siehe „Kann ich meinen Cache gezielt umgehen?“ weiter unten). Die Antwort wurde anschließend möglicherweise im Cache gespeichert.
• EXPIRED – Der Eintrag im Cache ist abgelaufen. Die Antwort enthält aktuelle Inhalte vom Ursprungsserver.
• STALE – Der Inhalt ist veraltet, da der Ursprungsserver nicht ordnungsgemäß antwortet und proxy_cache_use_stale konfiguriert wurde.
• UPDATING – Der Inhalt ist veraltet, da der Eintrag derzeit als Reaktion auf eine vorherige Anfrage aktualisiert wird und proxy_cache_use_stale updating konfiguriert ist.
• REVALIDATED – Die Direktive proxy_cache_revalidate war aktiviert und NGINX hat überprüft, dass der aktuell zwischengespeicherte Inhalt noch gültig war (If-Modified-Since oder If-None-Match).
• HIT – Die Antwort enthält gültige, aktuelle Inhalte direkt aus dem Cache.

Wie entscheidet NGINX, ob etwas zwischengespeichert wird?

NGINX speichert eine Antwort nur dann im Cache, wenn der Ursprungsserver entweder den Expires-Header mit einem in der Zukunft liegenden Datum und einer entsprechenden Uhrzeit oder den Cache-Control-Header mit der Direktive max-age und einem Wert ungleich null sendet.

Standardmäßig berücksichtigt NGINX weitere Direktiven im Cache-Control-Header: Antworten werden nicht zwischengespeichert, wenn der Header die Direktive Private, No-Cache oder No-Store enthält. Auch Antworten mit dem Set-Cookie-Header werden nicht zwischengespeichert. Darüber hinaus werden nur Antworten auf GET- und HEAD-Anfragen zwischengespeichert. Sie können diese Standardeinstellungen wie in den nachfolgenden Antworten beschrieben überschreiben.

NGINX speichert Antworten nicht im Cache, wenn proxy_buffering auf off gesetzt ist. Standardmäßig ist die Einstellung on.

Können Cache-Control-Header ignoriert werden?

Ja, mit der Direktive proxy_ignore_headers. Zum Beispiel mit dieser Konfiguration:

location /images/ {
    proxy_cache my_cache;
    proxy_ignore_headers Cache-Control;
    proxy_cache_valid any 30m;
    # ...
}

NGINX ignoriert den Cache-Control-Header für alle Inhalte unter /images/. Die Direktive proxy_cache_valid legt eine Ablaufzeit für die zwischengespeicherten Daten fest und ist erforderlich, wenn Cache-Control-Header ignoriert werden. NGINX speichert keine Dateien zwischen, für die keine Ablaufzeit festgelegt ist.

Kann NGINX Inhalte mit einem Set-Cookie im Header zwischenspeichern?

Ja, mit der Direktive „proxy_ignore_headers“, wie in der vorherigen Antwort erläutert.

Kann NGINX POST-Anfragen zwischenspeichern?

Ja, mit der proxy_cache_methods-Direktive:

proxy_cache_methods GET HEAD POST;

Dieses Beispiel aktiviert das Caching von POST-Anfragen.

Kann NGINX dynamische Inhalte zwischenspeichern?

Ja, sofern der Cache-Control-Header dies zulässt. Selbst wenn dynamische Inhalte nur für kurze Zeit zwischengespeichert werden, kann dies die Last auf Ursprungsservern und Datenbanken reduzieren. Dadurch verkürzt sich die Zeit bis zum ersten Byte, da die Seite nicht für jede Anfrage neu generiert werden muss.

Kann ich meinen Cache gezielt umgehen?

Ja, mit der proxy_cache_bypass-Direktive:

location / {
    proxy_cache_bypass $cookie_nocache $arg_nocache;
    # ...
}

Die Direktive legt die Arten von Anfragen fest, bei denen NGINX Inhalte sofort vom Ursprungsserver abruft, anstatt zunächst zu versuchen, sie im Cache zu finden. Dies wird manchmal als „Loch im Cache“ bezeichnet. In diesem Beispiel geschieht dies bei Anfragen mit einem nocache-Cookie oder -Argument, zum Beispiel http://www.example.com/?nocache=true. NGINX kann die resultierende Antwort weiterhin für zukünftige Anfragen zwischenspeichern, die den Cache nicht umgehen.

Welchen Cache-Schlüssel verwendet NGINX?

Die von NGINX generierten Schlüssel entsprechen standardmäßig in etwa einem MD5-Hash der folgenden NGINX-Variablen: $scheme$proxy_host$request_uri; der tatsächlich verwendete Algorithmus ist etwas komplexer.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g                 inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

Für diese Beispielkonfiguration wird der Cache-Schlüssel für http://www.example.org/my_image.jpg wie folgt berechnet: md5(“http://my_upstream:80/my_image.jpg”).

Beachten Sie, dass die Variable „$proxy_host“ im Hashwert anstelle des tatsächlichen Hostnamens (www.example.com) verwendet wird. „$proxy_host“ ist als Name und Port des Proxyservers definiert, wie in der Direktive „proxy_pass“ angegeben.

Um die Variablen (oder andere Ausdrücke) zu ändern, die als Grundlage für den Schlüssel verwendet werden, verwenden Sie die Direktive proxy_cache_key (siehe auch die folgende Frage).

Kann ich ein Cookie als Teil meines Cache-Schlüssels verwenden?

Ja, der Cache-Schlüssel kann auf einen beliebigen Wert festgelegt werden, zum Beispiel:

proxy_cache_key $proxy_host$request_uri$cookie_jessionid;

In diesem Beispiel wird der Wert des JSESSIONID-Cookies in den Cache-Schlüssel aufgenommen. Elemente mit demselben URI, aber unterschiedlichen JSESSIONID-Werten werden separat als eindeutige Elemente im Cache gespeichert.

Verwendet NGINX den ETag-Header?

Ab NGINX 1.7.3 und NGINX Plus R5 wird der ETag-Header zusammen mit If-None-Match vollständig unterstützt.

Wie verarbeitet NGINX Bytebereichsanfragen?

Wenn die Datei im Cache aktuell ist, berücksichtigt NGINX eine Bytebereichsanfrage und stellt dem Client nur die angegebenen Bytes des Elements bereit. Wenn die Datei nicht im Cache gespeichert oder veraltet ist, lädt NGINX die gesamte Datei vom Ursprungsserver herunter. Bezieht sich die Anfrage auf einen einzelnen Bytebereich, sendet NGINX diesen Bereich an den Client, sobald er im Download-Datenstrom erreicht wird. Gibt die Anfrage mehrere Bytebereiche innerhalb derselben Datei an, stellt NGINX dem Client nach Abschluss des Downloads die gesamte Datei bereit.

Sobald der Download abgeschlossen ist, verschiebt NGINX die gesamte Ressource in den Cache, sodass alle zukünftigen Bytebereichsanfragen – unabhängig davon, ob sie einen einzelnen oder mehrere Bereiche betreffen – sofort aus dem Cache bedient werden.

Beachten Sie, dass der upstream-Server Bytebereichsanfragen unterstützen muss, damit NGINX Bytebereichsanfragen an diesen upstream-Server berücksichtigt.

Unterstützt NGINX das Leeren des Caches?

NGINX Plus unterstützt das gezielte Löschen zwischengespeicherter Dateien. Dies ist nützlich, wenn eine Datei auf dem Ursprungsserver aktualisiert wurde, im Cache von NGINX Plus aber noch gültig ist (Cache-Control:max-age ist noch gültig und das durch den Parameter inactive der Direktive proxy_cache_path festgelegte Zeitlimit ist noch nicht abgelaufen). Mit der Cache-Löschfunktion von NGINX Plus lässt sich diese Datei problemlos löschen. Weitere Informationen finden Sie unter Inhalte aus dem Cache löschen.

Wie behandelt NGINX den Pragma-Header?

Der Header Pragma:no-cache wird von Clients hinzugefügt, um alle zwischengeschalteten Caches zu umgehen und den angeforderten Inhalt direkt vom Ursprungsserver abzurufen. Standardmäßig berücksichtigt NGINX den Header Pragma nicht. Sie können diese Funktion jedoch mit der folgenden Direktive proxy_cache_bypass konfigurieren:

location /images/ {
    proxy_cache my_cache;
    proxy_cache_bypass $http_pragma;
    # ...
}

Unterstützt NGINX die Erweiterungen stale-while-revalidate und stale-if-error für den Cache-Control-Header?

Ja, ab NGINX Plus R12 und NGINX 1.11.10. Diese Erweiterungen bewirken Folgendes:

• Die stale-while-revalidate-Erweiterung des Cache-Control-HTTP-Headers ermöglicht die Verwendung einer veralteten zwischengespeicherten Antwort, wenn diese gerade aktualisiert wird.
• Die stale-if-error-Erweiterung des Cache-Control-HTTP-Headers ermöglicht es, im Fehlerfall eine veraltete zwischengespeicherte Antwort zu verwenden.

Diese Header haben eine niedrigere Priorität als die oben beschriebene Direktive „proxy_cache_use_stale“.

Unterstützt NGINX den Vary-Header?

Ja, ab NGINX Plus R5 und NGINX 1.7.7. Hier finden Sie einen guten Überblick über den Vary-Header.

Weiterführende Literatur

Es gibt noch viele weitere Möglichkeiten, das NGINX-Caching anzupassen und zu optimieren. Weitere Informationen zum Caching mit NGINX finden Sie in den folgenden Ressourcen:

• Die Referenzdokumentation zu ngx_http_proxy_module enthält alle Konfigurationsoptionen für das Caching von Inhalten.
• Zwei Webinare sind auf Abruf verfügbar und behandeln einen Großteil der in diesem Blogbeitrag vorgestellten Informationen: „Content-Caching mit NGINX Plus“ und „Hochverfügbares Content-Caching mit NGINX“.
• Der NGINX Plus-Administratorleitfaden enthält weitere Konfigurationsbeispiele und Informationen zur Optimierung des NGINX-Caches.
• Die Produktseite zum NGINX Plus-Caching bietet einen Überblick über die Konfiguration der Cache-Bereinigung mit NGINX Plus sowie weitere Beispiele für die Anpassung des Caches.
• Das E-Book „Hochleistungs-Caching mit NGINX und NGINX Plus“ bietet einen umfassenden Einblick in das Content-Caching mit NGINX.

Über den Autor

Faisal MemonSoftwareentwickler

Weitere Blogbeiträge von Faisal Memon