Grundlegendes Caching mit Nginx: Verbesserung der Antwortzeiten

Grundlegendes Caching mit Nginx kann die Antwortzeiten verbessern, indem eine Kopie der Upstream-Antworten gespeichert und erneut ausgeliefert wird, ohne jedes Mal die Anwendung zu fragen. Bei sorgfältiger Anwendung reduziert Caching die Backend-Last, glättet Traffic-Spitzen und lässt wiederholte Anfragen schneller erscheinen.

Caching ist nicht nur für große Websites. Selbst eine kleine App kann profitieren, wenn Seiten, API-Antworten oder statische Dateien häufig angefordert werden und sich nicht jede Sekunde ändern.

Was Nginx cachen kann

Nginx kann Antworten von einem Upstream-Server cachen, wenn es als Reverse-Proxy fungiert. Dies unterscheidet sich vom normalen Browser-Caching. Browser-Caching speichert Dateien auf dem Gerät des Benutzers. Nginx-Proxy-Caching speichert Antworten auf dem Server, sodass viele Benutzer von derselben gecachten Kopie profitieren können.

Ein einfaches Proxy-Cache-Setup besteht aus zwei Teilen. Definieren Sie zunächst eine Cache-Zone im http-Block:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
    max_size=1g inactive=60m use_temp_path=off;

Aktivieren Sie dann diesen Cache in einem server- oder location-Block:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_valid 404 1m;
    add_header X-Cache-Status $upstream_cache_status;
}

Die Direktive proxy_cache_path erstellt den Cache-Speicherbereich. keys_zone definiert gemeinsamen Speicher für Cache-Schlüssel und Metadaten. max_size begrenzt die Festplattennutzung. inactive entfernt Elemente, die eine Weile nicht abgerufen wurden.

Die proxy_cache_valid-Direktiven legen fest, wie lange bestimmte Antwortcodes im Cache bleiben. Im Beispiel werden erfolgreiche Antworten 10 Minuten lang gecacht, während 404-Antworten 1 Minute lang gecacht werden.

Der X-Cache-Status-Header ist während des Testens nützlich. Er kann Werte wie MISS, HIT, BYPASS oder EXPIRED anzeigen, je nachdem, was passiert ist.

Für Websites, die Nginx auch als Reverse-Proxy verwenden, passt dies natürlich mit dem Reverse-Proxy-Setup zusammen.

Entscheiden, was gecacht werden sollte

Der schwierigste Teil des Nginx-Cachings ist nicht das Schreiben der Direktiven. Es ist die Entscheidung, welche Inhalte sicher wiederverwendet werden können.

Gute Caching-Kandidaten sind:

• Öffentliche Marketingseiten.
• Öffentliche Dokumentationsseiten.
• Produktlistenseiten, die nach einem vorhersehbaren Zeitplan aktualisiert werden.
• Anonyme API-Antworten.
• Teure Upstream-Antworten, die für viele Benutzer identisch sind.

Schlechte Caching-Kandidaten sind:

• Kontoseiten.
• Warenkörbe.
• Admin-Bildschirme.
• Antworten, die private Benutzerdaten enthalten.
• Seiten, die sich basierend auf Cookies oder Autorisierungs-Headern ändern.

Wenn eine Antwort für jeden Benutzer unterschiedlich ist, cachen Sie sie nicht, es sei denn, Sie haben eine sehr klare Cache-Key-Strategie. Das versehentliche Ausliefern der privaten Antwort eines Benutzers an einen anderen Benutzer ist ein schwerwiegender Fehler.

Sie können Caching umgehen, wenn Anfragen Sitzungs- oder Autorisierungsdaten enthalten:

proxy_cache_bypass $http_authorization;
proxy_no_cache $http_authorization;

Für cookie-basierte Sitzungen können Sie ein ähnliches Muster verwenden:

proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;

Der genaue Cookie-Name hängt von Ihrer Anwendung ab. Kopieren Sie dies nicht blind, ohne zu überprüfen, wie Ihre App Sitzungen handhabt.

Ein praktisches Szenario: Ihre öffentliche Blog-Startseite wird von einer Anwendung generiert und benötigt an einem geschäftigen Tag 300 Millisekunden. Wenn Sie diese Seite für 5 Minuten cachen, erhalten die meisten Besucher schnell die gecachte Kopie, und die App generiert sie nur gelegentlich neu. Das ist ein starker Anwendungsfall, da die Startseite öffentlich und nicht benutzerspezifisch ist.

Cache-Schlüssel, Header und Löschen

Nginx verwendet einen Cache-Schlüssel, um zu entscheiden, ob zwei Anfragen dieselbe gecachte Antwort teilen sollen. Der Standard-Cache-Schlüssel basiert normalerweise auf Schema, Methode, Host und URI. Für viele Websites ist das ausreichend.

Wenn Abfragezeichenfolgen die Antwort ändern, stellen Sie sicher, dass sie Teil des Schlüssels sind. Wenn Abfragezeichenfolgen nur Tracking-Parameter sind, möchten Sie sie möglicherweise auf Anwendungs- oder CDN-Ebene normalisieren, anstatt dass jedes utm_source einen separaten Cache-Eintrag erstellt.

Upstream-Cache-Header sind ebenfalls wichtig. Ihre App kann Header wie diese senden:

Cache-Control: public, max-age=600

oder:

Cache-Control: private, no-store

Nginx kann so konfiguriert werden, dass diese Header respektiert oder überschrieben werden, aber Sie sollten eine klare Richtlinie wählen. Wenn App-Entwickler erwarten, dass Cache-Control: no-store Caching verhindert, kann das Überschreiben dieses Verhaltens bei Nginx zu verwirrenden und riskanten Ergebnissen führen.

Das Löschen ist eine weitere betriebliche Frage. Open-Source-Nginx enthält keinen einfachen integrierten Cache-Lösch-Endpunkt wie einige kommerzielle oder Drittanbieter-Module. Viele Teams handhaben dies, indem sie kurze Cache-Dauern, versionierte URLs oder Bereitstellungsskripte verwenden, die das Cache-Verzeichnis während kontrollierter Releases leeren.

Kurze TTLs sind oft ausreichend. Ein 60-Sekunden-Cache auf einem vielbesuchten Endpunkt kann immer noch eine große Menge an Backend-Traffic entfernen, während der Inhalt einigermaßen aktuell bleibt.

Testen des Cache-Verhaltens

Nachdem Sie Caching aktiviert haben, fordern Sie dieselbe URL mehrmals an und überprüfen Sie die Antwort-Header:

curl -I https://example.com/

Wenn Sie X-Cache-Status hinzugefügt haben, zeigt die erste Anfrage möglicherweise MISS, und spätere Anfragen sollten HIT anzeigen. Wenn jede Anfrage ein MISS ist, überprüfen Sie Antwort-Header, Cache-Umgehungsregeln, Anfrage-Cookies und ob das Cache-Verzeichnis vom Nginx-Worker-Prozess beschreibbar ist.

Testen Sie auch das Verhalten bei angemeldeten und abgemeldeten Benutzern. Hier zeigen sich viele Caching-Fehler. Öffnen Sie ein privates Browserfenster, melden Sie sich als Testbenutzer an und bestätigen Sie, dass private Seiten nicht öffentlich gecacht werden.

Überwachen Sie auch die Festplattennutzung. Ein Cache ohne praktische Grenze kann ein Dateisystem füllen. Verwenden Sie max_size, halten Sie Cache-Speicher nach Möglichkeit von kritischen Systempartitionen getrennt und alarmieren Sie bei Festplattenbelastung.

Wann Sie Hilfe holen sollten

Holen Sie einen erfahrenen Nginx- oder Plattformingenieur hinzu, wenn gecachte Inhalte unter dem falschen Benutzer erscheinen, wenn Ihre Cache-Trefferquote nach der Optimierung niedrig bleibt oder wenn Cache-Dateien unerwartet die Festplatte füllen. Caching-Probleme können einfach aussehen, während sie anwendungsspezifisches Verhalten verbergen.

Sie sollten auch Hilfe holen, bevor Sie authentifizierte APIs, Multi-Tenant-Dashboards oder zahlungsbezogene Abläufe cachen. Diese Bereiche erfordern ein sorgfältiges Design.

Grundlegendes Caching mit Nginx funktioniert am besten, wenn Sie mit öffentlichen, wiederholbaren Antworten und kurzen Cache-Dauern beginnen. Fügen Sie während des Testens sichtbare Cache-Status-Header hinzu, respektieren Sie die Grenzen privater Inhalte und messen Sie sowohl Antwortzeit als auch Backend-Last. Gut gemacht, gibt Caching Benutzern schnellere Seiten, während Ihre Anwendung Raum zum Atmen hat.