Ursprünglicher Autor: Alan Murphy von F5

Ursprünglicher Link: Vorschläge und Techniken zur Leistungsoptimierung

Nachdruckquelle: Offizielle chinesische Website von NGINX

Die einzige offizielle chinesische Community von NGINX, alle unter nginx.org.cn

Mehrere Mitglieder des NGINX-Teams haben zu diesem Artikel beigetragen, darunter Valentin Bartenev und Nick Shadrin.

In den letzten Jahren habe ich mit Partnern zusammengearbeitet, für die die Leistung von NGINX Plus im Vordergrund stand. Unsere Gespräche beginnen oft mit der Schwierigkeit, unsere veröffentlichten Leistungsmaßstäbe zu erfüllen . Probleme wie dieses treten normalerweise auf, weil sie direkt zu einem bestimmten Anwendungsfall springen, z. B. der Verwendung eines vorhandenen SSL-Schlüssels oder dem Ziel sehr großer Dateilasten, und dann feststellen, dass die Leistung von NGINX Plus unterdurchschnittlich ist.

In gewisser Weise ist dieses Ergebnis nicht überraschend. Ich erkläre meinen Partnern immer, dass NGINX Plus als Softwarekomponente in der Lage ist, auf jeder verfügbaren Hardware mit nahezu linearer Geschwindigkeit zu laufen, wenn es um die grundlegendsten HTTP-Anwendungsfälle geht. Um jedoch unsere veröffentlichte theoretische Leistung in einem bestimmten Anwendungsfall zu erreichen, erfordert NGINX Plus häufig bestimmte Anpassungen in der Konfiguration, dem zugrunde liegenden Betriebssystem und dem Hardware-Setup.

Bisher konnten unsere Partner in jedem Anwendungsfall einen ganz individuellen Anwendungsfall erreichen, indem sie einfach Betriebssystemkomponenten und Hardwareeinstellungen konfigurierten und die Interaktion von NGINX Plus mit diesen Komponenten basierend auf dem spezifischen Anwendungsszenario anpassten. Lassen Sie NGINX Plus theoretische Ergebnisse erzielen Leistung.

Nach jahrelanger Prüfung habe ich eine Liste mit Vorschlägen und Tipps zur Anpassung der NGINX-Konfiguration, des Betriebssystems und der Hardware zusammengestellt, in der Hoffnung, unseren Partnern und Kunden dabei zu helfen, die Leistung von NGINX Open Source Edition und NGINX Plus in bestimmten Anwendungsfällen zu verbessern. .

Dieser Artikel bietet nur Anleitungen zu einer Teilmenge der Konfigurationseinstellungen, die sich auf die Leistung auswirken können. Er deckt nicht alle Aspekte der NGINX-Leistungsoptimierung ab und ist auch nicht unbedingt zum Ändern aller unten beschriebenen Einstellungen in Ihrer Umgebung geeignet.

Hinweis: Dieser Blogbeitrag wurde seit seiner Erstveröffentlichung überarbeitet und wird weiter überprüft, um sicherzustellen, dass er so vollständig wie möglich ist. Gerne können Sie Ihre Änderungen und zusätzlichen Vorschläge im Kommentarbereich unten hinzufügen. Wir werden diese gegebenenfalls übernehmen.

Tuning-Workflow

Bei Problemen mit der NGINX-Leistungsoptimierung empfehle ich im Allgemeinen den folgenden Workflow:

Versuchen Sie, die Leistung von NGINX Plus in den häufigsten HTTP-Anwendungsfällen zu testen, um die richtige Testbasis für Ihre Umgebung festzulegen.
Machen Sie sich Ihren Anwendungsfall klar. Wenn Ihre Anwendung beispielsweise das Hochladen großer Dateien erfordert oder Sie SSL-Schlüssel mit größerer Länge verarbeiten möchten, definieren Sie zunächst das Endziel Ihres Anwendungsfalls.
Konfigurieren Sie NGINX Plus für Ihren Anwendungsfall und testen Sie es erneut, um festzustellen, wie sich die tatsächliche Leistung von der theoretischen Leistung in Ihrer Umgebung unterscheidet.
Konzentrieren Sie sich auf die Einstellungen, die am besten zu Ihrem Anwendungsfall passen, und passen Sie jeweils eine Einstellung an. Mit anderen Worten: Fügen Sie nicht eine neue NGINX-Direktive hinzu und ändern Sie gleichzeitig eine Reihe von Systemctl-Einstellungen. Sie sollten klein anfangen, insbesondere mit den Funktionen, die für Ihren Anwendungsfall am relevantesten sind. Wenn beispielsweise eine hohe Sicherheit für Ihre Umgebung von entscheidender Bedeutung ist, passen Sie zunächst den Typ und die Länge des SSL-Schlüssels an.
Wenn eine Änderung die Leistung nicht verbessert, setzen Sie sie wieder auf die Standardeinstellungen zurück. Während Sie die einzelnen Einstellungen einzeln anpassen, werden Sie feststellen, dass sich einige verwandte Einstellungen gemeinsam auf die Leistung auswirken. Bei einer zukünftigen Optimierung können Sie diese Einstellungen dann als Ganzes nach Bedarf anpassen.

Es ist wichtig zu beachten, dass jede Bereitstellungsumgebung einzigartig ist und ihre eigenen Anforderungen an die Netzwerk- und Anwendungsleistung hat. Wir empfehlen, einige Einstellungen in einer Produktionsumgebung nicht zu ändern. Die Auswirkungen der im Folgenden beschriebenen Konfigurationsanpassungen können je nach Anwendungstyp und Netzwerktopologie erheblich variieren.

Angesichts der starken Verankerung von NGINX in der Open-Source-Community haben im Laufe der Jahre viele Menschen Feedback und Beiträge zur Verbesserung der Leistung eingebracht. Dieser Artikel fügt gegebenenfalls Links zu einigen externen Ressourcen hinzu und stellt einige konkrete Vorschläge zur Leistungsoptimierung vor, die nach tatsächlichen Produktionstests gemacht wurden.

Passen Sie die NGINX-Konfiguration an

Einzelheiten zu den zulässigen Werten, Standardeinstellungen und Einstellungsbereichen für jede Einstellung finden Sie in der NGINX-Referenzdokumentation .

SSL

In diesem Abschnitt wird beschrieben, wie Sie langsame und unnötige Verschlüsselungen aus OpenSSL und NGINX entfernen .

Da die SSL-Leistung so wichtig ist, ist es oft notwendig, mit verschiedenen Schlüssellängen und -typen in Ihrer Umgebung zu experimentieren. Dies kann Ihnen helfen, ein Gleichgewicht zwischen „langem Schlüssel, hohe Sicherheit“ und „kurzem Schlüssel, hohe Leistung“ zu finden und gleichzeitig spezifische Sicherheitsanforderungen zu erfüllen. Hier ist ein einfacher Test: Wechseln Sie von einem traditionelleren RSA-Schlüssel zu Elliptic Curve Cryptozoology (ECC), das eine kürzere Schlüssellänge verwendet und daher eine schnellere Berechnung bei gleichem Sicherheitsniveau ermöglicht. Geschwindigkeit.

Führen Sie den folgenden Befehl aus, um schnell einen selbstsignierten ECC P-256-Schlüssel zum Testen zu generieren:

# openssl ecparam -out ./nginx-ecc-p256.key -name prime256v1 -genkey
# openssl req -new -key ./nginx-ecc-p256.key -out ./nginx-ecc-p256-csr.pem -subj '/CN=localhost'
# openssl req -x509 -nodes -days 30 -key ./nginx-ecc-p256.key -in ./nginx-ecc-p256-csr.pem -out ./nginx-ecc-p256.pem

Kompression

Gzip-Parameter bieten eine detaillierte Kontrolle darüber, wie NGINX Inhalte bereitstellt. Eine falsche Einstellung kann daher zu einer Verschlechterung der NGINX-Leistung führen. Durch die Aktivierung von gzip kann Bandbreite gespart und die Seitenladegeschwindigkeit bei langsamen Verbindungen verbessert werden. (Die Auswirkung der Aktivierung von gzip auf lokal ausgeführte synthetische Benchmarks kann von der tatsächlichen Nutzung abweichen.) Für maximale Leistung können Sie die folgenden Einstellungen ausprobieren:

Aktivieren Sie gzip nur für relevante Inhalte wie Text-, JavaScript- und CSS-Dateien.
Erhöhen Sie nicht die Komprimierungsstufe, da dies den CPU-Ressourcenverbrauch ohne entsprechende Durchsatzverbesserungen erhöht.
Aktivieren Sie gzip für verschiedene Arten und Größen von Inhalten und deaktivieren Sie gzip, um die Auswirkungen zu bewerten Komprimierung aktivieren;
Weitere Informationen zur feinkörnigen Steuerung von gzip finden Sie in der Referenzdokumentation des NGINX-gzip-Moduls .

Verbindungshandling

Hier finden Sie mehrere Optimierungsoptionen im Zusammenhang mit der Verbindungsverarbeitung. Informationen zur korrekten Syntax und den anwendbaren Konfigurationsblöcken (http, Server, Standort) finden Sie in der verlinkten Referenzdokumentation.

Accept_mutexoff – Alle Arbeitsprozesse werden über neue Verbindungen benachrichtigt (Standard in NGINX 1.11.3 und höher, NGINX Plus R10 und höher). Wenn diese Option aktiviert ist, akzeptieren Arbeitsprozesse abwechselnd neue Verbindungen.
Keepalive 128 – Ermöglicht Keepalive-Verbindungen von NGINX Plus zum Upstream-Server und definiert die maximale Anzahl inaktiver Keepalive-Verbindungen, die im Cache jedes Arbeitsprozesses beibehalten werden. Wenn dieser Wert überschritten wird, wird die zuletzt verwendete Verbindung geschlossen. Wenn keine Keepalives festgelegt sind, entsteht mehr Overhead und weder Verbindungen noch kurzlebige Ports werden effektiv genutzt.

Wenn Sie diese Direktive für HTTP-Verkehr in einem Upstream-Block verwenden, müssen Sie auch die folgenden Direktiven zur Konfiguration hinzufügen, um sicherzustellen, dass sie in allen Standortblöcken der Upstream-Servergruppe angewendet werden (Sie können sie in einzelnen Standortblöcken platzieren, übergeordnete). Servercodeblock oder http-Ebene): Proxy_http_Version 1.1 – NGINX Plus verwendet HTTP/1.1, um Proxy-Anfragen zu verarbeiten. Proxy_set_header Connection „“ – NGINX Plus entfernt alle Verbindungsanforderungsheader von Proxy-Anfragen

multi_accept off – Ein Arbeitsprozess akzeptiert jeweils nur eine neue Verbindung (Standard). Wenn diese Option aktiviert ist, empfängt ein Arbeitsprozess alle neuen Verbindungen auf einmal. Sofern Sie nicht sicher sind, dass die Änderung einen Vorteil bringt, empfehlen wir, den Standardwert (aus) beizubehalten. Leistungstests mit Standardwerten helfen dabei, vorhersehbare Ergebnisse besser zu messen.
Proxy_buffering on – NGINX Plus empfängt Antworten vom Proxyserver so schnell wie möglich und puffert sie (Standard). Wenn diese Option deaktiviert ist, übermittelt NGINX Plus Antworten synchron an den Client, sobald sie empfangen werden, was die Belastung von NGINX Plus erhöht. Das Deaktivieren der Antwortpufferung ist nur für Anwendungen erforderlich, die sofortigen Zugriff auf den Datenstrom benötigen.
listen 80 reuseport – Port-Sharding aktivieren, was bedeutet, dass für jeden Worker-Prozess ein separater Listening-Socket erstellt wird (mithilfe der Socket-Option SO_REUSEPORT). Dadurch kann der Kernel empfangene Verbindungen an verschiedene Worker-Prozesse verteilen. . Weitere Informationen finden Sie in unserem Blogbeitrag: Socket Sharding in NGINX Release 1.9.1 .

Protokoll

Die Protokollierung ist ein wichtiges Werkzeug zur Verwaltung und Prüfung von Systemen. Das Protokollieren großer Datenmengen und das Speichern großer Protokollmengen kann die Systemressourcen belasten. Wir empfehlen daher, die Protokollierung nur unter ganz bestimmten Umständen oder bei der Fehlerbehebung bei der Leistung zu deaktivieren.

access_log off – Zugriffsprotokollierung deaktivieren.
access_log /path/to/access.log main buffer=16k – Aktivieren Sie die Zugriffsprotokoll-Pufferfunktion.

Viele Open-Source-Projekte und kommerzielle Produkthersteller bieten zentralisierte Protokollierungssysteme basierend auf dem Syslog-Protokoll . Dieses System kann Ihnen Komfort bieten. Wenn Sie jedoch Metriken für NGINX- und NGINX Plus-Server benötigen, die die ursprünglich in den Protokollen aufgezeichneten Informationen konsolidieren, können Sie NGINX Amplify verwenden .

Thread-Pool

Der Thread-Pool besteht aus einer Aufgabenwarteschlange und mehreren Threads, die die Warteschlange verarbeiten. Wenn ein Arbeitsprozess eine möglicherweise lange Operation ausführen muss, verarbeitet er die Operation nicht selbst, sondern stellt die Aufgabe in die Warteschlange des Thread-Pools, sodass jeder inaktive Thread sie abrufen und verarbeiten kann.

Um Thread-Pooling zu aktivieren, fügen Sie die Direktive aio threads hinzu. Beachten Sie, dass die Verwaltung des Thread-Pools durch andere pufferbezogene Konfigurationseinstellungen beeinflusst werden kann. Ausführliche Informationen zum Anpassen zusätzlicher Einstellungen zur Unterstützung von Thread-Pools finden Sie in unserem Blogbeitrag .

Cpu affinität

CPU-Affinität gibt an, welchen CPU-Kern oder welche CPU-Kerne NGINX Plus für jeden Arbeitsprozess verwendet (Hintergrundinformationen finden Sie in der Referenzdokumentation zu worker_cpu_affinity).

In den meisten Fällen empfehlen wir die Verwendung des automatischen Standardparameters worker_processes, der die Anzahl der Arbeitsprozesse so festlegt, dass sie mit der Anzahl der verfügbaren CPU-Kerne übereinstimmt.

Wenn NGINX Plus jedoch in einer Containerumgebung wie Docker ausgeführt wird, entscheiden sich Systemadministratoren möglicherweise dafür, dem Container weniger Kernelressourcen zuzuweisen, als auf dem Hostcomputer verfügbar sind. In diesem Fall erkennt NGINX Plus die Anzahl der auf dem Host verfügbaren Kerne und rotiert die Arbeitsprozesse zwischen den tatsächlich für den Container verfügbaren Kernen. In diesem Fall sollte der Wert von worker_processes als die Anzahl der tatsächlich im Container verfügbaren Kerne angegeben werden, um die Anzahl der Worker-Prozesse zu reduzieren.

Testen Sie die CPU-Affinität

Normalerweise empfehlen wir beim Testen, dass Sie Datenverkehr verwenden, der Ihrem Produktionsdatenverkehr ähnelt. Für grundlegende Tests können Sie jedoch einen Traffic-Generator wie wrk verwenden, wie hier beschrieben.

Arbeitssitzungen für NGINX Plus schnell laden:

# wrk -t 1 -c 50 -d 20s http://localhost/1k.bin

Bei Bedarf können Sie zum Testen eine einfache 1k.bin-Datei erstellen:

# dd if=/dev/zero of=1kb.bin bs=1024 count=1

Führen Sie den Top-Befehl im CPU-Überwachungsmodus aus (drücken Sie 1, nachdem Top gestartet wurde).

Sie können die Linearität testen, indem Sie mit einer unterschiedlichen Anzahl von Arbeitsprozessen und Affinitätsbindungseinstellungen iterieren. Dies ist eine effiziente Möglichkeit, Zugriffsbeschränkungen für einen geeigneten Teil der verfügbaren Kerne festzulegen.

Auswahlvorschläge

Hier finden Sie eine grobe Einführung in einige ungefähre Auswahlempfehlungen, die für normale Webdienste und Lastausgleich geeignet sind. Diese Werte sind möglicherweise nicht für VOD-Streaming-Medien oder CDN-Anwendungsszenarien geeignet.

CPU

Weisen Sie 1 CPU-Kern pro 1–2 Gbit/s unverschlüsseltem Datenverkehr zu.

Kleine (1–2 KB) Antworten und 1 Antwort pro Verbindung erhöhen die CPU-Auslastung.

RAM

Weisen Sie 1 GB RAM für das Betriebssystem und andere allgemeine Anforderungen zu.

Der Rest wird NGINX Plus-Puffer, Socket-Puffer und virtuellen Speichercache zugewiesen, was einer groben Schätzung von 1 MB pro Verbindung entspricht.

Weitere Auswahlvorschläge finden Sie auf der offiziellen Website der NGINX-Community

Festplatten-E/A

Die Festplatten-E/A wird durch E/A-Vorgänge pro Sekunde (IOPS) begrenzt.

Viele Funktionen von NGINX Plus basieren auf Festplatten-I/O und IOPS, wie z. B. Protokollierung und Caching.