Nginx-Inhaltscache und allgemeine Parameterkonfigurationsdetails

Anwendungsszenarien:

Die Seiten des Projekts müssen viele Daten laden, die sich nicht häufig ändern und keine personalisierte Anpassung erfordern. Das dynamische Generieren von Daten für jede Anfrage ist nicht so leistungsfähig wie das Zwischenspeichern der Ergebnisse basierend auf Anfragerouting und -parametern. Die Verwendung des Nginx-Cache erhöht die Anfragegeschwindigkeit erheblich.

Base

Sie müssen nur proxy_cache_path und proxy_cache konfigurieren, um das Inhalts-Caching zu aktivieren. Ersteres wird verwendet, um den Cache-Pfad und die Konfiguration festzulegen, und letzteres wird verwendet, um das Caching zu aktivieren.

http {
 ...
 proxy_cache_path /Pfad/zum/Cache levels=1:2 keys_zone=my_cache:10m max_size=10g inaktiv=60m use_temp_path=aus;

 Server {
 Proxy_Cache mein Cache;
 Standort / {
  Proxy-Passwort http://localhost:8000;
 }
 }
}

Entsprechende Parameterbeschreibung:

1. Das für die Zwischenspeicherung verwendete lokale Datenträgerverzeichnis ist /path/to/cache/

2.levels richtet ein zweistufiges Hierarchieverzeichnis in /Pfad/zum/Cache/ ein. Das Platzieren einer großen Anzahl von Dateien in einem einzigen Verzeichnis kann zu langsamen Dateizugriffen führen. Daher empfehlen wir für die meisten Bereitstellungen eine zweistufige Verzeichnishierarchie. Wenn der Ebenenparameter nicht konfiguriert ist, platziert NGINX alle Dateien im selben Verzeichnis.

3.keys_zone legt eine gemeinsam genutzte Speicherzone fest, die zum Speichern von Cache-Schlüsseln und Metadaten verwendet wird, was dem Zweck eines Timers ähnelt. Durch das Ablegen einer Kopie des Schlüssels im Speicher kann NGINX schnell feststellen, ob es sich bei einer Anforderung um einen Treffer oder einen Fehlschlag handelt, ohne die Festplatte durchsuchen zu müssen. Dadurch wird die Suchgeschwindigkeit erheblich verbessert. In einem 1 MB großen Speicherplatz können etwa 8.000 Schlüssel gespeichert werden. Der oben konfigurierte 10 MB große Speicherplatz kann also etwa 80.000 Schlüssel speichern.

4. max_size legt die Obergrenze des Cache fest (10 G im obigen Beispiel). Dies ist optional. Wenn Sie keinen Wert angeben, kann der Cache kontinuierlich wachsen und den gesamten verfügbaren Speicherplatz belegen. Wenn der Cache diese Grenze erreicht, ruft der Prozessor den Cache-Manager auf, um die am wenigsten kürzlich verwendeten Dateien zu entfernen und so den Cache-Speicherplatz unter diese Grenze zu reduzieren.

5.inactive gibt an, wie lange ein Element im Speicher verbleiben kann, ohne dass darauf zugegriffen wird. Wenn im obigen Beispiel eine Datei nicht innerhalb von 60 Minuten angefordert wurde, löscht der Cache-Manager sie automatisch aus dem Speicher, unabhängig davon, ob die Datei abgelaufen ist. Der Standardwert dieses Parameters beträgt 10 Minuten (10 m). Beachten Sie, dass inaktiver Inhalt sich von abgelaufenem Inhalt unterscheidet. NGINX löscht abgelaufene Inhalte, die durch den Cache-Control-Header angegeben sind (in diesem Fall Cache-Control:max-age=120), nicht automatisch. Abgelaufene Inhalte werden nur gelöscht, wenn innerhalb der angegebenen Inaktivitätszeit nicht darauf zugegriffen wurde. Wenn auf abgelaufene Inhalte zugegriffen wird, aktualisiert NGINX diese vom ursprünglichen Server und den entsprechenden Inaktivitäts-Timer.

6. NGINX platziert die für den Cache bestimmten Dateien zunächst in einem temporären Speicherbereich. Der Befehl use_temp_path=off weist NGINX an, diese Dateien beim Zwischenspeichern in dasselbe Verzeichnis zu schreiben. Wir empfehlen dringend, diesen Parameter auf „Aus“ zu setzen, um unnötiges Kopieren von Daten im Dateisystem zu vermeiden. use_temp_path wurde in NGINX Version 1.7 und NGINX Plus R6 eingeführt.

Schließlich ermöglicht die Direktive „proxy_cache“ das Zwischenspeichern von Inhalten für URLs, die mit dem Standortteil übereinstimmen (in diesem Fall /). Sie können dem Serverabschnitt auch eine Proxy_Cache-Direktive hinzufügen, die das Caching auf alle Server am Standort anwendet, die keine eigene Proxy_Cache-Direktive angeben.

Mit dem Nginx-Cache verbundene Prozesse

Am Caching sind zwei weitere NGINX-Prozesse beteiligt:

• Der Cache-Manager wird regelmäßig gestartet, um den Status des Cache zu überprüfen. Wenn die Cachegröße den durch den Parameter max_size in proxy_cache_path festgelegten Grenzwert überschreitet, löscht der Cache-Manager kürzlich aufgerufene Daten. In der Zeit zwischen den Starts des Cache-Managers kann die Menge der zwischengespeicherten Daten vorübergehend die konfigurierte Größe überschreiten.
• Der Cache Loader wird nur einmal ausgeführt, nachdem NGINX gestartet ist. Es lädt Metadaten zu zuvor zwischengespeicherten Daten in den gemeinsam genutzten Speicherbereich. Das gleichzeitige Laden des gesamten Caches kann so viele Ressourcen verbrauchen, dass die Leistung von NGINX in den ersten Minuten nach dem Start beeinträchtigt wird. Um dies zu vermeiden, konfigurieren Sie das iterative Laden des Caches, indem Sie den folgenden Parameter in die Direktive proxy_cache_path aufnehmen:
  • loader_threshold – Iterationsdauer in Millisekunden (standardmäßig 200)
  • loader_files – Maximale Anzahl der während einer Iteration geladenen Elemente (standardmäßig 100)
  • loader_sleeps – Verzögerung zwischen Iterationen in Millisekunden (standardmäßig 50)

Im folgenden Beispiel dauern die Iterationen 300 Millisekunden oder bis 200 Elemente geladen wurden:

Proxy-Cache-Pfad /Daten/nginx/Cache Keys_Zone=eins:10m Loader_Schwellenwert=300 Loader_Dateien=200;

Andere allgemeine Parameter

Konfigurationsbeispiel:

proxy_cache_path /Pfad/zum/Cache levels=1:2 keys_zone=my_cache:10m max_size=10g inaktiv=60m use_temp_path=aus;

Server {
 ...
 Standort / {
  Proxy-Cache mein_Cache;
  # proxy_cache_key "$host$request_uri$cookie_user"; proxy_cache_min_uses 3;
  Proxy_Cache_Methoden: Kopf-Beitrag abrufen;
  Proxy_Cache_gültig 200 302 10 m;
  Proxy_Cache_gültig 404 1m;
  # proxy_cache_valid alle 5m; proxy_pass http://localhost:8000;
 }
}

Entsprechende Parameterbeschreibung:

• proxy_cache_key gibt den Cache-Schlüssel an, um die Anforderungseigenschaften zu ändern, die bei der Berechnung des Schlüssels verwendet werden. Dies wird nicht empfohlen. Ein Beispiel ist die Verwendung des Domänennamens, der Anforderungs-URL und des Benutzercookies als Schlüssel, was bedeutet, dass eine Seite n-mal für verschiedene Benutzer zwischengespeichert wird. In den meisten Fällen ist ein solcher Vorgang nicht erforderlich.
• proxy_cache_min_uses ist die Mindestanzahl von Anfragen, die denselben Schlüssel verwenden müssen, bevor die Antwort zwischengespeichert wird.
• proxy_cache_methods gibt die Antwortwerte der zu cachenden Anfragemethoden an. Die Standardwerte sind GET und HEAD. Wenn weitere Methoden hinzugefügt werden, müssen diese zusammen aufgelistet werden, wie im obigen Beispiel gezeigt.
• proxy_cache_valid ist die Cachezeit des Antwortstatuscodes. In diesem Beispiel können Sie für jeden Statuscode eine Cachezeit angeben oder „any“ verwenden, um alle Statuscodes zwischenzuspeichern.

Leeren Sie den Cache

Um Anfragen mit der HTTP-PURGE-Methode zu identifizieren und den Cache der entsprechenden URL zu löschen, ist vorab eine Konfiguration notwendig.

1. Erstellen Sie eine neue Variable im http {}-Kontext, beispielsweise $purge_method, die von der Variable $request_method abhängt:

http {
 ...
 Karte $Anforderungsmethode $Purge_Methode {
  SÄUBERN 1;
  Standardwert 0;
 }
}

2. Wenn der Cache konfiguriert wurde, geben Sie im Block „location {}“ den Parameter „proxy_cache_purge“ ein, um die Bedingungen zum Löschen von Cache-Anfragen festzulegen. Geben Sie beispielsweise im vorherigen Schritt $request_method an

Server {
 hören Sie 80;
 Servername www.example.com;

 Standort / {
  Proxy-Passwort https://localhost:8002;
  Proxy_Cache mein Cache;

  Proxy-Cache-Purge $purge_method;
 }
}

Nach der Konfiguration und Aktivierung können Sie eine Löschanforderung senden, um den Cache ungültig zu machen, zum Beispiel:

curl -X PURGE -D – https://www.example.com/*

In diesem Beispiel werden Ressourcen mit einem öffentlichen URL-Teil (angegeben durch das Platzhalterzeichen „Stern“) gelöscht. Diese Cacheeinträge werden jedoch nicht vollständig aus dem Cache entfernt: Sie verbleiben auf der Festplatte, bis sie als inaktiv eingestuft werden (festgelegt durch den Parameter „inactive“ in „proxy_cache_path“), bis der Cache geleert wird (festgelegt durch „purge“ in „proxy_cache_path“) oder bis ein Client versucht, auf sie zuzugreifen.

Referenzlinks:

• Offizieller Leitfaden zur Verwendung von Nginx Cache
• Dokumentation zum Zwischenspeichern von Nginx-Inhalten

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.