Im Laufe jedes Projekts kommt die Zeit, in der der Server die SLA-Anforderungen nicht mehr erfüllt und buchstäblich beginnt, die Menge des eingehenden Datenverkehrs zu drosseln. Danach beginnt der lange Prozess des Auffindens von Engpässen, umfangreichen Abfragen, falsch erstellten Indizes, nicht zwischengespeicherten Daten oder umgekehrt, zu häufig aktualisierten Daten im Cache und anderen dunklen Seiten des Projekts.
Aber was tun, wenn Ihr Code „perfekt“ ist, alle umfangreichen Anforderungen im Hintergrund stehen, alles, was möglich war, zwischengespeichert wurde und der Server die von uns benötigten SLA-Indikatoren immer noch nicht erreicht? Wenn möglich, können Sie natürlich neue Autos kaufen, einen Teil des Verkehrs verteilen und das Problem für eine Weile vergessen.
Wenn Sie jedoch das Gefühl haben, dass Ihr Server mehr kann oder es einen magischen Parameter gibt, der die Site um das 100-fache beschleunigt, können Sie die integrierte Nginx-Funktion aufrufen, mit der Sie Antworten aus dem Backend zwischenspeichern können. Lassen Sie uns einen Blick darauf werfen, was es ist und wie es dazu beitragen kann, die Anzahl der vom Server verarbeiteten Anforderungen zu erhöhen.
Was ist der Nginx-Cache und wie funktioniert er?
Der Nginx-Cache kann die Anzahl der Anforderungen für das Backend erheblich reduzieren. Dies wird erreicht, indem die HTTP-Antwort für eine bestimmte Zeit gespeichert wird und beim erneuten Zugriff auf die Ressource aus dem Cache zurückgegeben wird, ohne die Anforderung für das Backend zu übertragen. Durch das Zwischenspeichern wird die Anzahl der vom Server verarbeiteten Anforderungen selbst für einen kurzen Zeitraum erheblich erhöht.
Bevor Sie mit der Konfiguration von nginx fortfahren, müssen Sie sicherstellen, dass es mit dem Modul „ngx_http_proxy_module“ erstellt wurde, da wir es mit diesem Modul konfigurieren werden.
Zur Vereinfachung können Sie die Konfiguration in eine separate Datei übertragen, z. B. "/etc/nginx/conf.d/cache.conf". Schauen wir uns die Anweisung proxy_cache_path an, mit der Sie die Cache-Speichereinstellungen konfigurieren können.
proxy_cache_path /var/lib/nginx/proxy_cache levels=1:2 keys_zone=proxy_cache:15m max_size=1G;
"/ Var / lib / nginx / proxy_cache" gibt den Cache-Speicherpfad auf dem Server an. In diesem Verzeichnis speichert nginx genau die Dateien mit der Antwort vom Backend. Gleichzeitig erstellt nginx nicht unabhängig ein Verzeichnis für den Cache. Sie müssen sich selbst darum kümmern.
"Levels = 1: 2" - Legt die Verschachtelungsebene von Verzeichnissen mit einem Cache fest. Verschachtelungsebenen werden durch ":" angezeigt. In diesem Fall werden 2 Verzeichnisse erstellt, insgesamt sind 3 Verschachtelungsebenen zulässig. Für jede Verschachtelungsebene stehen Werte von 1 bis 2 zur Verfügung, die angeben, wie der Verzeichnisname erstellt wird.
Der wichtige Punkt ist, dass der Verzeichnisname nicht zufällig ausgewählt wird, sondern basierend auf dem Dateinamen erstellt wird. Der Dateiname wiederum ist das Ergebnis der md5-Funktion aus dem Cache-Schlüssel. Wir werden uns den Cache-Schlüssel etwas später ansehen.
Lassen Sie uns in der Praxis sehen, wie der Pfad zur Cache-Datei erstellt wird:
/var/lib/nginx/proxy_cache/2/49/07edcfe6974569ab4da6634ad4e5d492
Der Parameter "Keys_zone = proxy_cache: 15m" legt den Namen der Zone im gemeinsam genutzten Speicher fest, in der alle aktiven Schlüssel und Informationen zu ihnen gespeichert sind. Durch ":" wird die Größe des zugewiesenen Speichers in MB angegeben. Laut nginx reicht 1 MB aus, um 8.000 Schlüssel zu speichern.
"Max_size = 1G" definiert die maximale Cache-Größe für alle Seiten, über denen nginx dafür sorgt, dass weniger benötigte Daten gelöscht werden.
Es ist auch möglich, die Lebensdauer der Daten im Cache zu steuern. Dazu reicht es aus, den Parameter "inaktiv" der Direktive "proxy_cache_path" zu definieren, der standardmäßig 10 Minuten beträgt. Wenn während der im Parameter "inaktiv" angegebenen Zeit keine Aufrufe der Cache-Daten aufgetreten sind, werden diese Daten gelöscht, auch wenn der Cache noch nicht "sauer" ist.
Wie ist dieser Cache? Dies ist eigentlich eine reguläre Datei auf dem Server, deren Inhalt geschrieben ist:
• Cache-Schlüssel;
• Cache-Header;
• Inhaltsantwort vom Backend.
Wenn mit den Headern und der Antwort vom Backend alles klar ist, gibt es eine Reihe von Fragen zum „Cache-Schlüssel“. Wie ist es aufgebaut und wie kann es verwaltet werden?
Um die Vorlage zum Erstellen eines Cache-Schlüssels in nginx zu beschreiben, gibt es eine Direktive proxy_cache_key, in der eine Zeichenfolge als Parameter angegeben wird. Eine Zeichenfolge kann aus beliebigen in nginx verfügbaren Variablen bestehen.
Zum Beispiel:
proxy_cache_key $request_method$host$orig_uri:$cookie_some_cookie:$arg_some_arg;
Das Symbol ":" zwischen dem Cookie-Parameter und dem get-Parameter wird verwendet, um Kollisionen zwischen Cache-Schlüsseln zu verhindern. Sie können ein beliebiges anderes Symbol Ihrer Wahl auswählen. Standardmäßig verwendet nginx die folgende Zeile, um den Schlüssel zu generieren:
proxy_cache_key $scheme$proxy_host$request_uri;
Die folgenden Anweisungen sollten beachtet werden, damit Sie Ihr Caching flexibler verwalten können:
proxy_cache_valid - Gibt die Antwort-Caching-Zeit an. Es ist möglich, den spezifischen Status der Antwort anzugeben, z. B. 200, 302, 404 usw., oder alles gleichzeitig mit dem Konstrukt "any" anzugeben. Wenn nur die Caching-Zeit angegeben wird, speichert nginx standardmäßig nur die Status 200, 301 und 302 zwischen.
Ein Beispiel:
proxy_cache_valid 15m; proxy_cache_valid 404 15s;
In diesem Beispiel haben wir die Cache-Lebensdauer für die Status 200, 301, 302 auf 15 Minuten festgelegt (nginx verwendet sie standardmäßig, da wir keinen bestimmten Status angegeben haben). In der nächsten Zeile wird die Caching-Zeit auf 15 Sekunden festgelegt, nur für Antworten mit dem Status 404.
proxy_cache_lock - Diese Anweisung hilft dabei, mehrere Durchgänge zum Backend unmittelbar nach einer Reihe von Caches zu vermeiden. Setzen Sie einfach den Wert auf die Position "Ein". Alle anderen Anforderungen warten auf eine Antwort im Cache oder auf eine Zeitüberschreitung beim Blockieren der Anforderung an die Seite. Dementsprechend können alle Zeitüberschreitungen konfiguriert werden.
proxy_cache_lock_age - Ermöglicht das
Festlegen eines Zeitlimits für eine Antwort vom Server.
Danach wird die nächste Anforderung an ihn gesendet, nachdem der Cache festgelegt wurde. Der Standardwert beträgt 5 Sekunden.
proxy_cache_lock_timeout - Legt die Wartezeit für die Sperre fest.
Danach wird die Anforderung an das Backend gesendet, die Antwort wird jedoch nicht zwischengespeichert. Der Standardwert beträgt 5 Sekunden.
proxy_cache_use_stale - Eine weitere nützliche Anweisung, mit der Sie konfigurieren können, wann ein veralteter Cache verwendet werden kann.
Ein Beispiel:
proxy_cache_use_stale error timeout updating;
In diesem Fall wird ein veralteter Cache verwendet, wenn ein Verbindungsfehler auftritt, eine Anforderung gesendet, eine Antwort vom Server gelesen, das Wartelimit für das Senden einer Anforderung überschritten, eine Antwort vom Server gelesen wird oder wenn die Daten im Cache zum Zeitpunkt der Anforderung aktualisiert werden.
proxy_cache_bypass - Gibt die Bedingungen an, unter denen nginx keine Antwort vom Cache entgegennimmt, sondern die Anforderung sofort an das Backend umleitet. Wenn mindestens einer der Parameter nicht leer ist und nicht gleich "0" ist. Ein Beispiel:
proxy_cache_bypass $cookie_nocache $arg_nocache;
proxy_no_cache - Legt die Bedingung fest, unter der nginx die Antwort vom Backend nicht im Cache speichert. Das Funktionsprinzip ist dasselbe wie das der Direktive proxy_cache_bypass.
Mögliche Probleme beim Zwischenspeichern von Seiten
Wie oben erwähnt, speichert nginx neben dem Zwischenspeichern einer HTTP-Antwort die vom Backend empfangenen Header. Wenn Ihre Site eine Sitzung verwendet, wird auch das Sitzungscookie zwischengespeichert. Alle Benutzer, die die Seite besuchen, die Sie zwischengespeichert haben, erhalten Ihre in der Sitzung gespeicherten persönlichen Daten.
Die nächste Herausforderung ist das Caching-Management. Natürlich können Sie eine unbedeutende Cache-Zeit von 2-5 Minuten festlegen, was in den meisten Fällen ausreicht. Dies gilt jedoch nicht in allen Situationen, sodass wir unser Fahrrad neu erfinden werden. Nun, das Wichtigste zuerst.
Verwaltung der Cookie-AufbewahrungDas Caching auf der Nginx-Seite unterwirft einige Designeinschränkungen. Beispielsweise können wir keine Sitzungen auf zwischengespeicherten Seiten verwenden, da der Benutzer das Backend nicht erreicht. Eine weitere Einschränkung ist die Bereitstellung von Cookies durch das Backend. Da nginx alle Header zwischenspeichert, müssen wir die Übermittlung von Cookies für zwischengespeicherte Seiten untersagen, um zu vermeiden, dass die Sitzung einer anderen Person im Cache gespeichert wird. Die Anweisung proxy_ignore_headers hilft uns dabei. Das Argument listet die Header auf, die im Backend ignoriert werden sollen.
Ein Beispiel:
proxy_ignore_headers "Set-Cookie";
Mit dieser Zeile ignorieren wir die Installation von Cookies vom Proxyserver, dh der Benutzer erhält eine Antwort ohne den Header "Set-Cookies". Dementsprechend wird alles, was das Backend versucht hat, in das Cookie zu schreiben, auf der Clientseite ignoriert, da es nicht einmal weiß, dass etwas dafür bestimmt war. Diese Cookie-Einschränkung sollte bei der Entwicklung einer Anwendung berücksichtigt werden. Um beispielsweise eine Autorisierung anzufordern, können Sie die Header-Zündung deaktivieren, damit der Benutzer ein Sitzungscookie erhält.
Sie sollten auch die Sitzungslebensdauer berücksichtigen. Sie kann im Parameter "
session.gc_maxlifetime " der Konfiguration "
php.ini " angezeigt werden. Stellen Sie sich vor, der Benutzer hat sich auf der Website angemeldet und den Newsfeed angezeigt. Alle Daten befinden sich bereits im Nginx-Cache. Nach einiger Zeit bemerkt der Benutzer, dass seine Autorisierung verschwunden ist und er den Autorisierungsprozess erneut durchlaufen muss, obwohl er die ganze Zeit auf der Website war und die Nachrichten sah. Dies geschah, weil nginx bei allen Anfragen das Ergebnis aus dem Cache zurückgab, ohne eine Anfrage an das Backend zu senden. Daher entschied das Backend, dass der Benutzer inaktiv war, und löschte nach einer in „
session.gc_maxlifetime “ angegebenen Zeit die Sitzungsdatei.
Um dies zu verhindern, können wir Backend-Anfragen emulieren. Senden Sie beispielsweise über Ajax eine Anfrage, die garantiert an das Backend weitergeleitet wird. Um den Nginx-Cache an das Backend zu übergeben, senden Sie einfach eine POST-Anfrage. Sie können auch die Regel aus der Direktive "proxy_cache_bypass" verwenden oder einfach den Cache für diese Seite deaktivieren. Die Anfrage muss nichts zurückgeben, es kann sich um eine Datei mit einer einzelnen Zeile handeln, die die Sitzung startet. Der Zweck einer solchen Anforderung besteht darin, die Lebensdauer der Sitzung zu verlängern, während sich der Benutzer auf der Site befindet, und nginx gibt die zwischengespeicherten Daten gewissenhaft an alle seine Anforderungen weiter.
Cache Flush ManagementZuerst müssen Sie die Anforderungen bestimmen, welches Ziel wir erreichen wollen. Nehmen wir an, unsere Website enthält einen Abschnitt mit einer Textsendung über beliebte Sportveranstaltungen. Wenn das Laden der Seite aus dem Cache erfolgt, kommen alle neuen Nachrichten in Sockets. Damit der Benutzer beim ersten Start aktuelle Nachrichten zum aktuellen Zeitpunkt und nicht vor 15 Minuten sehen kann, muss der Nginx-Cache jederzeit unabhängig gelöscht werden können. Gleichzeitig befindet sich nginx möglicherweise nicht auf demselben Computer wie die Anwendung. Eine der Voraussetzungen für ein Zurücksetzen ist auch die Möglichkeit, den Cache über mehrere Seiten gleichzeitig zu löschen.
Bevor Sie mit dem Schreiben Ihrer Lösung beginnen, schauen wir uns an, was nginx sofort bietet. Um den Cache zurückzusetzen, verfügt nginx über eine spezielle Anweisung namens "proxy_cache_purge", die die Bedingung für das Zurücksetzen des Caches aufzeichnet. Die Bedingung ist eigentlich eine normale Zeile, die, wenn sie nicht leer und nicht "0" ist, den Cache durch den übergebenen Schlüssel löscht. Betrachten Sie ein kleines Beispiel.
proxy_cache_path /data/nginx/cache keys_zone=cache_zone:10m; map $request_method $purge_method { PURGE 1; default 0; } server { ... location / { proxy_pass http://backend; proxy_cache cache_zone; proxy_cache_key $uri; proxy_cache_purge $purge_method; } }
Ein Beispiel stammt von der offiziellen Nginx-Website.Die Variable $ purge_method ist für das Leeren des Caches verantwortlich. Dies ist eine Bedingung für die Direktive proxy_cache_purge und wird standardmäßig auf 0 gesetzt. Dies bedeutet, dass nginx im „normalen“ Modus arbeitet (es speichert Antworten vom Backend). Wenn Sie jedoch die Anforderungsmethode in "PURGE" ändern, wird der Cache-Eintrag mit dem entsprechenden Caching-Schlüssel gelöscht, anstatt die Anforderung für das Backend durch Speichern der Antwort zu ersetzen. Es ist auch möglich, eine Löschmaske anzugeben, indem am Ende des Cache-Schlüssels ein "*" angegeben wird. Daher müssen wir den Speicherort des Caches auf der Festplatte und das Prinzip der Schlüsselbildung nicht kennen. Nginx übernimmt diese Verantwortung. Dieser Ansatz hat aber auch Nachteile.
- Die Direktive proxy_cache_purge ist als Teil eines kommerziellen Abonnements verfügbar.
- Es ist nur möglich, den Cache punktweise oder mithilfe der Maske des Formulars {Cache-Schlüssel} "*" zu löschen.
Da die Adressen zwischengespeicherter Seiten ohne gemeinsame Teile völlig unterschiedlich sein können, ist der Ansatz mit der Maske "*" und der Direktive "proxy_cache_purge" für uns nicht geeignet. Es bleibt, sich an eine kleine Theorie zu erinnern und Ihre Lieblingsidee zu entdecken.
Wir wissen, dass der Nginx-Cache eine reguläre Datei auf dem Server ist. Wir haben das Verzeichnis zum Speichern von Cache-Dateien unabhängig in der Direktive "proxy_cache_path" angegeben und sogar die Logik zum Bilden des Pfads zur Datei aus diesem Verzeichnis mithilfe von "Ebenen" angegeben. Das einzige, was uns fehlt, ist die korrekte Bildung des Caching-Schlüssels. Wir können es aber auch in der Direktive "proxy_cache_key" sehen. Jetzt müssen wir nur noch:
- Bilden Sie den vollständigen Pfad zur Seite, genau wie in der Anweisung proxy_cache_key angegeben.
- codiere den resultierenden String in md5;
- Erstellen Sie verschachtelte Verzeichnisse mit der Regel aus dem Parameter "Ebenen".
- Und jetzt haben wir bereits den vollständigen Pfad zur Cache-Datei auf dem Server. Jetzt müssen wir nur noch diese Datei löschen. Aus dem Einführungsteil wissen wir, dass sich nginx möglicherweise nicht auf dem Anwendungscomputer befindet. Daher müssen Sie es ermöglichen, mehrere Adressen gleichzeitig zu löschen. Wieder beschreiben wir den Algorithmus:
- Die generierten Pfade zu den Cache-Dateien werden in die Datei geschrieben.
- Schreiben wir ein einfaches Bash-Skript, das wir mit der Anwendung auf den Computer stellen. Seine Aufgabe wird es sein, über ssh eine Verbindung zu dem Server herzustellen, auf dem Nginx zwischengespeichert wird, und alle in der generierten Datei angegebenen Cache-Dateien aus Schritt 1 zu löschen.
Wir gehen von der Theorie zur Praxis über und schreiben ein kleines Beispiel, das unseren Arbeitsalgorithmus veranschaulicht.
Schritt 1. Generieren einer Datei mit Pfaden zum Cache.
$urls = [ 'httpGETdomain.ru/news/111/1:2', 'httpGETdomain.ru/news/112/3:4', ]; function to_nginx_cache_path(url) { $nginxHash = md5($url); $firstDir = substr($nginxHash, -1, 1); $secondDir = substr($nginxHash, -3, 2); return "/var/lib/nginx/proxy_cache/$firstDir/$secondDir/$nginxHash"; } // tmp $filePath = tempnam('tmp', 'nginx_cache_'); // $fileStream = fopen($filePath, 'a'); foreach ($urls as $url) { // $cachePath = to_nginx_cache_path($url); // fwrite($fileStream, $cachePath . PHP_EOL); } // fclose($fileStream); // bash exec("/usr/local/bin/cache_remover $filePath");
Bitte beachten Sie, dass die Variable $ urls die URL der zwischengespeicherten Seiten enthält, die bereits das in der nginx-Konfiguration angegebene Format proxy_cache_key hat. Die URL dient als Tag für die auf der Seite angezeigten Objekte. Sie können beispielsweise eine reguläre Tabelle in der Datenbank erstellen, in der jede Entität einer bestimmten Seite zugeordnet wird, auf der sie angezeigt wird. Wenn wir dann Daten ändern, können wir eine Auswahl in der Tabelle treffen und den Cache aller benötigten Seiten löschen.
Schritt 2. Stellen Sie eine Verbindung zum Cache-Server her und löschen Sie die Cache-Dateien.
# , FILE_LIST=`cat $1 | tr ` # ssh SSH=`which ssh` USER= # nginx HOST= # KEY= # SSH , $SSH -i ${KEY} ${USER}@${HOST} # rm -rf rm -f $1 #
Die obigen Beispiele dienen nur zur Orientierung. Verwenden Sie sie nicht in der Produktion. In den Beispielen werden die Überprüfungen von Eingabeparametern und Befehlsbeschränkungen weggelassen. Eines der Probleme, auf die Sie möglicherweise stoßen, besteht darin, die Länge des Arguments auf den Befehl rm zu beschränken. Beim Testen in einer Entwicklungsumgebung auf kleinen Volumes kann dies leicht übersehen werden, und in der Produktion wird der Fehler "rm: Argumentliste zu lang" angezeigt.
Benutzerdefiniertes Block-Caching
Fassen wir zusammen, was wir geschafft haben:
- reduzierte die Belastung des Backends;
- Erfahren Sie, wie Sie das Caching verwalten
- habe gelernt, den Cache jederzeit zu leeren.
Aber nicht alles ist so gut, wie es auf den ersten Blick scheinen mag. Nun, wahrscheinlich, wenn nicht jede erste, dann hat genau jede zweite Site eine Registrierungs- / Autorisierungsfunktion, nach deren Durchlauf wir den Benutzernamen irgendwo in der Kopfzeile anzeigen möchten. Der Block mit dem Namen ist eindeutig und sollte den Benutzernamen anzeigen, unter dem wir autorisiert sind. Da nginx die Antwort vom Backend speichert und es sich bei der Seite um den HTML-Inhalt der Seite handelt, wird der Block mit den persönlichen Daten ebenfalls zwischengespeichert. Alle Besucher der Site sehen den Namen des ersten Benutzers, der für einen Satz Cache an das Backend übergeben wurde.
Daher sollte das Backend keine Blöcke angeben, in denen sich persönliche Informationen befinden, damit diese Informationen nicht unter den Nginx-Cache fallen.
Es ist notwendig, ein alternatives Laden solcher Teile der Seite in Betracht zu ziehen. Wie immer kann dies auf viele Arten erfolgen, z. B. nach dem Laden der Seite, Senden einer Ajax-Anfrage und Anzeigen des Loaders anstelle von persönlichem Inhalt. Eine andere Möglichkeit, die wir heute betrachten werden, ist die Verwendung von ssi-Tags. Lassen Sie uns zuerst verstehen, was SSI ist und wie wir es dann in Verbindung mit dem Nginx-Cache verwenden können.
Was ist SSI und wie funktioniert es?
SSI (Server-Side Includes, Server-Side Inclusions) ist eine Reihe von Befehlen, die in eine HTML-Seite eingebettet sind und dem Server mitteilen, was zu tun ist.
Hier ist eine Liste solcher Befehle (Anweisungen):
• if / elif / else / endif - Der Verzweigungsoperator;
• echo - Zeigt die Werte von Variablen an.
• include - Ermöglicht das Einfügen des Inhalts einer anderen Datei in das Dokument.
Nur die letzte Richtlinie wird diskutiert. Die include-Direktive hat zwei Parameter:
• Datei - Gibt den Pfad zur Datei auf dem Server an. In Bezug auf das aktuelle Verzeichnis;
• virtuell - Gibt den virtuellen Pfad zum Dokument auf dem Server an.
Wir interessieren uns für den Parameter „virtuell“, da die Angabe des vollständigen Pfads zur Datei auf dem Server nicht immer bequem ist oder bei einer verteilten Architektur die Datei auf dem Server einfach nicht vorhanden ist. Beispielanweisung:
Damit nginx mit der Verarbeitung von SSI-Einfügungen beginnen kann, müssen Sie den Speicherort wie folgt ändern:
location / { ssi on; ... }
Jetzt können alle vom Standort "/" verarbeiteten Anforderungen SSI-Einfügungen ausführen.
Wie wird unsere Anfrage dieses ganze Schema durchlaufen?
- der Client fordert die Seite an;
- Nginx überträgt die Anfrage für das Backend.
- Das Backend enthält die Seite mit SSI-Einfügungen.
- Das Ergebnis wird im Cache gespeichert.
- Nginx "fragt" nach den fehlenden Blöcken;
- Die resultierende Seite wird an den Client gesendet.
Wie Sie den Schritten entnehmen können, gelangen ssi-Konstrukte in den Nginx-Cache, wodurch persönliche Blöcke nicht zwischengespeichert werden können, und dem Client wird eine vorgefertigte HTML-Seite mit allen Einfügungen gesendet. Hier funktioniert unser Laden, nginx fordert unabhängig die fehlenden Seitenblöcke an. Aber wie jede andere Lösung hat auch dieser Ansatz Vor- und Nachteile. Stellen Sie sich vor, es gibt mehrere Blöcke auf der Seite, die je nach Benutzer unterschiedlich angezeigt werden sollten. Dann wird jeder dieser Blöcke durch eine SSI-Einfügung ersetzt. Wie erwartet fordert Nginx jeden solchen Block vom Backend an, dh eine Anfrage des Benutzers generiert sofort mehrere Anfragen für das Backend, die ich überhaupt nicht möchte.
Dauerhafte Backend-Anfragen über ssi loswerden
Um dieses Problem zu lösen, hilft uns das Nginx-Modul „ngx_http_memcached_module“. Das Modul ermöglicht den Empfang von Werten vom zwischengespeicherten Server. Das Schreiben durch das Modul funktioniert nicht, der Anwendungsserver sollte sich darum kümmern. Betrachten Sie ein kleines Beispiel für die Konfiguration von nginx in Verbindung mit einem Modul:
server { location /page { set $memcached_key "$uri"; memcached_pass 127.0.0.1:11211; error_page 404 502 504 = @fallback; } location @fallback { proxy_pass http://backend; } }
In der Variablen $ memcache_key haben wir den Schlüssel angegeben, mit dem nginx versucht, Daten aus dem Memcache abzurufen. Die Parameter für die Verbindung zum Memcache-Server werden in der Anweisung memcached_pass festgelegt. Die Verbindung kann auf verschiedene Arten angegeben werden:
• Domainname;
memcached_pass cache.domain.ru;
• IP-Adresse und Port;
memcached_pass localhost:11211;
• Unix-Socket;
memcached_pass unix:/tmp/memcached.socket;
• vorgelagerte Richtlinie.
upstream cachestream { hash $request_uri consistent; server 10.10.1.1:11211; server 10.10.1.2:11211; } location / { ... memcached_pass cachestream; ... }
Wenn es nginx gelungen ist, eine Antwort vom Cache-Server zu erhalten, gibt sie diese an den Client weiter. Befinden sich keine Daten im Cache, wird die Anfrage über "@fallback" an das Backend gesendet. Diese kleine Einrichtung des zwischengespeicherten Moduls unter nginx hilft uns, die Anzahl der übergebenen Anforderungen für das Backend von SSI-Einfügungen zu reduzieren.
Wir hoffen, dass dieser Artikel hilfreich war und wir eine der Möglichkeiten zur Optimierung der Serverauslastung aufzeigen, die Grundprinzipien für das Einrichten des Nginx-Caching berücksichtigen und die Probleme schließen konnten, die bei der Verwendung auftreten.