Detaillierte Erläuterung der Konfiguration und Optimierung des statischen Nginx-Dateidienstes

Stammverzeichnis und Indexdatei

Die Root-Direktive gibt das Stammverzeichnis an, das für die Suche nach Dateien verwendet wird. Um den Pfad zur angeforderten Datei zu erhalten, hängt NGINX die Anforderungs-URI an den durch die Root-Direktive angegebenen Pfad an. Diese Anweisung kann auf jeder Ebene innerhalb eines http{}-, server{}- oder location{}-Kontexts platziert werden. Im folgenden Beispiel wird eine Root-Direktive für einen virtuellen Server definiert. Dies gilt für alle Location-{}-Blöcke, die keine Root-Direktive enthalten, um die Root explizit neu zu definieren:

Server {
  Stammverzeichnis /www/data;

  Standort / {
  }

  Standort /Bilder/ {
  }

  Standort ~ \.(mp3|mp4) {
    Stammverzeichnis /www/media;
  }
}

Hier sucht NGINX im Verzeichnis /www/data/images/ im Dateisystem nach Dateien mit URIs, die mit /images/ beginnen. Wenn die URI mit der Erweiterung .mp3 oder .mp4 endet, sucht NGINX nach der Datei im Verzeichnis /www/media/, da sie in einem passenden Standortblock definiert ist.

Wenn die Anfrage mit / endet, behandelt NGINX sie als Anfrage für ein Verzeichnis und versucht, eine Indexdatei im Verzeichnis zu finden. Die Index-Direktive definiert den Namen der Indexdatei (der Standardwert ist index.html). Um mit dem Beispiel fortzufahren: Wenn die Anforderungs-URI /images/some/path/ lautet, gibt NGINX die Datei /www/data/images/some/path/index.html zurück, sofern sie existiert. Wenn nicht, gibt NGINX standardmäßig einen HTTP 404-Fehler (Nicht gefunden) zurück. Um NGINX so zu konfigurieren, dass automatisch generierte Verzeichnislisten zurückgegeben werden, fügen Sie der Autoindex-Direktive den Parameter „on“ hinzu:

Standort /Bilder/ {
  Autoindex aktiviert;
}

Sie können in der Indexdirektive mehrere Dateinamen auflisten. NGINX sucht in der angegebenen Reihenfolge nach Dateien und gibt die erste gefundene Datei zurück.

Standort / {
  Index index.$geo.html index.htm index.html;
}

Die hier verwendete Variable $geo ist eine benutzerdefinierte Variable, die über die Geo-Direktive festgelegt wurde. Der Wert der Variablen hängt von der IP-Adresse des Clients ab.

Um die Indexdatei zurückzugeben, prüft NGINX, ob sie existiert, und leitet dann intern zu einer neuen URI weiter, die durch Anhängen des Namens der Indexdatei an die Basis-URI erhalten wird. Eine interne Weiterleitung führt zu einer erneuten Suche nach einem Standort und kann an einem anderen Standort enden, wie das folgende Beispiel zeigt:

Standort / {
  Wurzel /Daten;
  Index Index.html Index.php;
}

Standort ~ \.php {
  fastcgi_pass localhost:8000;
  #...

}

Wenn hier die URI in der Anforderung /path/ lautet und /data/path/index.html nicht existiert, /data/path/index.php jedoch schon, dann wird die interne Weiterleitung zu /path/index.php dem zweiten Speicherort zugeordnet. Die Anfrage wird daher weitergeleitet.

Probieren Sie einige Optionen aus

Mit der Direktive „try_files“ können Sie prüfen, ob eine angegebene Datei oder ein angegebenes Verzeichnis vorhanden ist. Andernfalls führt NGINX eine interne Umleitung durch und gibt den angegebenen Statuscode zurück. Um beispielsweise zu überprüfen, ob eine Datei vorhanden ist, die der Anforderungs-URI entspricht, verwenden Sie die Direktive try_files und die Variable $uri wie folgt:

Server {
  Stammverzeichnis /www/data;

  Standort /Bilder/ {
    versuche_dateien $uri /images/default.gif;
  }
}

Die Datei wird als URI angegeben und mit den im Kontext des aktuellen Standorts oder virtuellen Servers festgelegten Root- oder Alias-Direktiven verarbeitet. Wenn in diesem Fall die der ursprünglichen URI entsprechende Datei nicht existiert, leitet NGINX intern zur durch den letzten Parameter angegebenen URI weiter und gibt /www/data/images/default.gif zurück.

Das letzte Argument kann auch ein Statuscode (direkt vorangestelltem Gleichheitszeichen) oder ein Ortsname sein. Wenn im folgenden Beispiel keines der Argumente der Direktive „try_files“ zu einer vorhandenen Datei oder einem vorhandenen Verzeichnis aufgelöst wird, wird ein 404-Fehler zurückgegeben.

Standort / {
  versuche_dateien $uri $uri/ $uri.html =404;
}

Wenn im nächsten Beispiel weder die ursprüngliche URI noch die URI mit dem zusätzlichen abschließenden Schrägstrich zu einer vorhandenen Datei oder einem vorhandenen Verzeichnis aufgelöst werden kann, wird die Anforderung an den angegebenen Speicherort umgeleitet und an den Proxyserver übergeben.

Standort / {
  versuche_dateien $uri $uri/ @backend;
}

Standort @backend {
  Proxy-Passwort http://backend.example.com;
}

Weitere Informationen finden Sie im Webinar zum Content-Caching. Dort erfahren Sie, wie Sie die Website-Leistung deutlich steigern und die Caching-Funktionen von NGINX besser verstehen können.

Optimieren Sie die Leistung von Serviceinhalten

Die Ladegeschwindigkeit ist ein entscheidender Faktor bei der Bereitstellung von Inhalten. Durch kleine Optimierungen Ihrer NGINX-Konfiguration können Sie die Produktivität steigern und zu einer optimalen Leistung beitragen.

Sendfile aktivieren

Standardmäßig übernimmt NGINX die Dateiübertragung selbst und kopiert die Dateien vor dem Senden in einen Puffer. Durch Aktivieren der Sendfile-Direktive entfällt der Schritt des Kopierens der Daten in einen Puffer und Daten können direkt von einem Dateideskriptor in einen anderen kopiert werden. Um zu verhindern, dass eine schnelle Verbindung den Arbeitsprozess völlig überlastet, kann alternativ die Direktive sendfile_max_chunk verwendet werden, um die Datenmenge zu begrenzen, die in einem einzelnen sendfile()-Aufruf übertragen wird (in diesem Fall auf 1 MB):

Standort /mp3 {
  sendfile an;
  sendfile_max_chunk 1m;
  #...

}

Aktivieren Sie tcp_nopush

Verwenden Sie die Direktive „tcp_nopush“ mit der Direktive „sendfile on;“. Dadurch kann NGINX die HTTP-Antwortheader in einem einzelnen Paket senden, unmittelbar nachdem sendfile() den Datenblock abgerufen hat.

Standort /mp3 {
  sendfile an;
  tcp_nopush ein;
  #...

}

Aktivieren Sie tcp_nodelay

Mit der Direktive tcp_nodelay kann der Nagle-Algorithmus außer Kraft gesetzt werden, der ursprünglich zur Lösung des Problems kleiner Pakete in langsamen Netzwerken entwickelt wurde. Der Algorithmus fasst viele kleine Pakete zu einem größeren Paket zusammen und sendet das Paket mit einer Verzögerung von 200 Millisekunden. Heutzutage können beim Bereitstellen großer statischer Dateien die Daten unabhängig von der Paketgröße sofort gesendet werden. Die Latenz wirkt sich auch auf Online-Anwendungen aus (SSH, Online-Gaming, Online-Handel usw.). Standardmäßig ist die Direktive „tcp_nodelay“ auf „on“ gesetzt, was bedeutet, dass der Nagle-Algorithmus deaktiviert ist. Diese Anweisung wird nur für Keepalive-Verbindungen verwendet:

Standort /mp3 {
  tcp_nodelay ein;
  KeepAlive-Timeout 65;
  #...
  
}

Optimieren der Backlog-Warteschlange

Ein wichtiger Faktor ist, wie schnell NGINX eingehende Verbindungen verarbeiten kann. Die allgemeine Regel lautet, dass eine Verbindung beim Herstellen in die „Abhör“-Warteschlange des Abhörsockets gestellt wird. Bei normaler Auslastung gibt es kaum oder gar keine Warteschlangen. Bei hoher Belastung können die Warteschlangen jedoch erheblich länger werden, was zu Leistungseinbußen, Verbindungsabbrüchen und längeren Latenzen führt.

Zeigen Sie die Backlog-Warteschlange an. Verwenden Sie den Befehl netstat -Lan, um die aktuelle Abhörwarteschlange anzuzeigen. Die Ausgabe könnte wie folgt aussehen. Sie zeigt, dass sich in der Abhörwarteschlange auf Port 80 10 nicht akzeptierte Verbindungen befinden, von den konfigurierten maximal 128 in die Warteschlange gestellten Verbindungen. Das ist normal.

Aktuelle Listenqueue-Größen (qlen/incqlen/maxqlen)
Lokale Adresse anhören     
0/0/128 *.12345      
10/0/128 *.80    
0/0/128 *.8080

Im Gegensatz dazu überschreitet im folgenden Befehl die Anzahl der nicht akzeptierten Verbindungen (192) den Grenzwert von 128. Dies kommt häufig vor, wenn auf der Website viel Verkehr herrscht. Um eine optimale Leistung zu erzielen, müssen Sie in Ihrem Betriebssystem und Ihrer NGINX-Konfiguration die maximale Anzahl an Verbindungen erhöhen, die in die Warteschlange für NGINX eingereiht werden können.

Aktuelle Listenqueue-Größen (qlen/incqlen/maxqlen)
Lokale Adresse anhören     
0/0/128 *.12345      
192/0/128 *.80    
0/0/128 *.8080

Anpassen des Betriebssystems

Erhöhen Sie den Wert des Kernelparameters net.core.somaxconn vom Standardwert (128) auf einen Wert, der groß genug ist, um dem hohen Datenverkehr gerecht zu werden. In diesem Beispiel wird es auf 4096 erhöht.

• Der Befehl für FreeBSD lautet sudo sysctl kern.ipc.somaxconn=4096
• Der Linux-Befehl lautet 1. sudo sysctl -w net.core.somaxconn=4096 2. Fügen Sie net.core.somaxconn = 4096 zur Datei /etc/sysctl.conf hinzu.

NGINX optimieren

Wenn Sie den Kernelparameter „somaxconn“ auf einen Wert größer als 512 setzen, erhöhen Sie den Backlog-Parameter in der NGINX-Listendirektive, sodass er der Änderung entspricht:

Server {
  hören Sie 80 Rückstand = 4096;
  # ...

}

© Dieser Artikel wurde aus Nginx Serving Static Content übersetzt, wobei einige semantische Anpassungen vorgenommen wurden.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.