NGINX für die Leistung optimieren

NGINX ist als leistungsstarker Load Balancer , Cache und Webserver bekannt und betreibt über 40 % der meistgenutzten Websites der Welt. Für die meisten Anwendungsfälle funktionieren die Standardeinstellungen für NGINX und Linux gut, manchmal sind zum Erreichen einer optimalen Leistung jedoch geringfügige Anpassungen erforderlich. In diesem Blogbeitrag werden einige der NGINX- und Linux-Einstellungen erläutert, die beim Optimieren eines Systems zu berücksichtigen sind.

Sie können fast jede Einstellung optimieren, dieser Beitrag konzentriert sich jedoch auf die wenigen Einstellungen, bei denen die Optimierung für die meisten Benutzer von Vorteil ist. Bei manchen Einstellungen empfehlen wir Ihnen, diese nur zu ändern, wenn Sie über fundierte Kenntnisse von NGINX und Linux verfügen oder wenn Sie von unseren Support- oder Professional Services -Teams dazu aufgefordert werden. Auf diese gehen wir hier nicht ein. Das Professional Services-Team hat mit einigen der meistbesuchten Websites der Welt zusammengearbeitet, um NGINX für ein maximales Leistungsniveau zu optimieren, und steht Ihnen gerne zur Verfügung, um mit Ihnen zusammen das Beste aus Ihrer NGINX- oder NGINX Plus-Bereitstellung herauszuholen.

Einführung

Ein grundlegendes Verständnis der NGINX-Architektur und Konfigurationskonzepte wird vorausgesetzt. Dieser Beitrag versucht nicht, die NGINX-Dokumentation zu duplizieren, sondern bietet einen Überblick über die verschiedenen Optionen und Links zur relevanten Dokumentation.

Eine gute Regel beim Optimieren besteht darin, immer nur eine Einstellung zu ändern und sie auf den Standardwert zurückzusetzen, wenn die Änderung keine Leistungsverbesserung mit sich bringt.

Wir beginnen mit einer Diskussion über die Linux-Optimierung, da der Wert einiger Betriebssystemeinstellungen bestimmt, wie Sie Ihre NGINX-Konfiguration optimieren.

Optimieren Ihrer Linux-Konfiguration

Die Einstellungen in modernen Linux-Kerneln (2.6+) sind für die meisten Zwecke geeignet, aber die Änderung einiger davon kann von Vorteil sein. Suchen Sie im Kernel-Protokoll nach Fehlermeldungen, die darauf hinweisen, dass eine Einstellung zu niedrig ist, und passen Sie sie den Empfehlungen entsprechend an. Hier behandeln wir nur die Einstellungen, die bei normaler Arbeitslast am wahrscheinlichsten von einer Optimierung profitieren. Einzelheiten zum Anpassen dieser Einstellungen finden Sie in Ihrer Linux-Dokumentation.

Die Backlog-Warteschlange

Die folgenden Einstellungen beziehen sich auf Verbindungen und deren Warteschlangeneinordnung. Wenn Sie eine hohe Anzahl eingehender Verbindungen haben und die Leistung unterschiedlich ist (beispielsweise scheinen einige Verbindungen ins Stocken zu geraten), kann das Ändern dieser Einstellungen hilfreich sein.

• net.core. somaxconn – Die maximale Anzahl von Verbindungen, die zur Annahme durch NGINX in die Warteschlange gestellt werden können. Der Standardwert ist oft sehr niedrig und das ist normalerweise akzeptabel, da NGINX Verbindungen sehr schnell akzeptiert. Es kann sich jedoch lohnen, den Wert zu erhöhen, wenn Ihre Website viel Verkehr hat. Wenn Fehlermeldungen im Kernel-Log darauf hinweisen, dass der Wert zu klein ist, erhöhen Sie ihn, bis keine Fehler mehr auftreten.

  Notiz: Wenn Sie dies auf einen Wert größer als 512 festlegen, ändern Sie den Backlog -Parameter entsprechend in die NGINX- Listen- Direktive.

• net.core. netdev_max_backlog – Die Rate, mit der Pakete von der Netzwerkkarte gepuffert werden, bevor sie an die CPU übergeben werden. Durch Erhöhen des Werts kann die Leistung auf Maschinen mit hoher Bandbreite verbessert werden. Suchen Sie im Kernel-Protokoll nach Fehlern im Zusammenhang mit dieser Einstellung und lesen Sie die Dokumentation der Netzwerkkarte, um Hinweise zum Ändern der Einstellung zu erhalten.

Dateideskriptoren

Dateideskriptoren sind Betriebssystemressourcen, die unter anderem zur Darstellung von Verbindungen und zum Öffnen von Dateien verwendet werden. NGINX kann bis zu zwei Datei-Deskriptoren pro Verbindung verwenden. Wenn NGINX beispielsweise als Proxy fungiert, wird im Allgemeinen ein Dateideskriptor für die Clientverbindung und ein anderer für die Verbindung zum Proxyserver verwendet. Bei der Verwendung von HTTP-Keepalives ist dieses Verhältnis jedoch viel niedriger. Bei einem System mit einer großen Anzahl an Verbindungen müssen möglicherweise die folgenden Einstellungen angepasst werden:

• sys.fs.file -max – Das systemweite Limit für Dateideskriptoren
• nofile – Das Benutzerdateideskriptorlimit, festgelegt in der Datei /etc/security/limits.conf

Temporäre Ports

Wenn NGINX als Proxy fungiert, verwendet jede Verbindung zu einem Upstream-Server einen temporären oder kurzlebigen Port. Möglicherweise möchten Sie diese Einstellung ändern:

• net.ipv4.ip_local_port_range – Anfang und Ende des Bereichs der Portwerte. Wenn Sie merken, dass Ihnen die verfügbaren Ports ausgehen, erhöhen Sie die Reichweite. Eine übliche Einstellung sind die Ports 1024 bis 65000.

Optimieren Ihrer NGINX-Konfiguration

Im Folgenden sind einige NGINX-Direktiven aufgeführt, die sich auf die Leistung auswirken können. Wie oben erwähnt, besprechen wir nur Anweisungen, die Sie sicher selbst anpassen können. Wir empfehlen, die Einstellungen anderer Anweisungen nicht ohne Anweisung des NGINX-Teams zu ändern.

Arbeitsprozesse

NGINX kann mehrere Arbeitsprozesse ausführen, von denen jeder eine große Anzahl gleichzeitiger Verbindungen verarbeiten kann. Sie können die Anzahl der Arbeitsprozesse und deren Verbindungshandhabung mit den folgenden Anweisungen steuern:

• worker_processes – Die Anzahl der NGINX-Arbeitsprozesse (der Standardwert ist 1). In den meisten Fällen funktioniert es gut, einen Arbeitsprozess pro CPU-Kern auszuführen. Um dies zu erreichen, empfehlen wir, diese Anweisung auf „auto“ zu setzen. Es kann vorkommen, dass Sie diese Zahl erhöhen möchten, z. B. wenn die Arbeitsprozesse viele Festplatten-E/A-Vorgänge durchführen müssen.
• worker_connections – Die maximale Anzahl an Verbindungen, die jeder Arbeitsprozess gleichzeitig verarbeiten kann. Der Standardwert ist 512, aber die meisten Systeme verfügen über genügend Ressourcen, um eine größere Zahl zu unterstützen. Die geeignete Einstellung hängt von der Größe des Servers und der Art des Datenverkehrs ab und kann durch Tests ermittelt werden.

Keepalive-Verbindungen

Keepalive-Verbindungen können die Leistung erheblich verbessern, indem sie den zum Öffnen und Schließen von Verbindungen erforderlichen CPU- und Netzwerk-Overhead reduzieren. NGINX beendet alle Client-Verbindungen und erstellt separate und unabhängige Verbindungen zu den Upstream-Servern. NGINX unterstützt Keepalives sowohl für Clients als auch für Upstream-Server. Die folgenden Anweisungen beziehen sich auf Client-Keepalives:

• keepalive_requests – Die Anzahl der Anfragen, die ein Client über eine einzelne Keepalive-Verbindung stellen kann. Der Standardwert ist 100, aber ein viel höherer Wert kann insbesondere beim Testen mit einem Lastgenerierungstool nützlich sein, das im Allgemeinen eine große Anzahl von Anforderungen von einem einzelnen Client sendet.
• keepalive_timeout – Wie lange eine inaktive Keepalive-Verbindung offen bleibt.

Die folgende Anweisung bezieht sich auf Upstream-Keepalives:

• Keepalive – Die Anzahl der inaktiven Keepalive-Verbindungen zu einem Upstream-Server, die für jeden Arbeitsprozess offen bleiben. Es gibt keinen Standardwert.

Um Keepalive-Verbindungen zu Upstream-Servern zu ermöglichen, müssen Sie außerdem die folgenden Anweisungen in die Konfiguration aufnehmen:

proxy_http_version 1.1; proxy_set_header Verbindung "";

Zugriffsprotokollierung

Das Protokollieren jeder Anforderung beansprucht sowohl CPU- als auch E/A-Zyklen. Eine Möglichkeit, die Auswirkungen zu reduzieren, besteht darin, die Zugriffsprotokollpufferung zu aktivieren. Anstatt für jeden Protokolleintrag einen separaten Schreibvorgang auszuführen, puffert NGINX beim Puffern eine Reihe von Einträgen und schreibt sie in einem einzigen Vorgang zusammen in die Datei.

Um die Pufferung von Zugriffsprotokollen zu aktivieren, schließen Sie den Parameter buffer= size in die Direktive access_log ein. NGINX schreibt den Pufferinhalt in das Protokoll, wenn der Puffer den Größenwert erreicht. Um NGINX anzuweisen, den Puffer nach einer angegebenen Zeitspanne zu schreiben, schließen Sie den Parameter „flush= time“ ein. Wenn beide Parameter gesetzt sind, schreibt NGINX Einträge in die Logdatei, wenn der nächste Logeintrag nicht in den Puffer passt bzw. die Einträge im Puffer älter als die angegebene Zeit sind. Protokolleinträge werden auch geschrieben, wenn ein Arbeitsprozess seine Protokolldateien erneut öffnet oder herunterfährt. Um die Zugriffsprotokollierung vollständig zu deaktivieren, fügen Sie der Direktive access_log den Parameter „off“ hinzu.

Sendedatei

Der Systemaufruf sendfile() des Betriebssystems kopiert Daten von einem Dateideskriptor in einen anderen und erreicht dabei häufig Zero‑Copy, was TCP‑Datenübertragungen beschleunigen kann. Um die Verwendung durch NGINX zu ermöglichen, schließen Sie die Sendfile- Direktive in den HTTP- Kontext oder einen Server- oder Standortkontext ein. NGINX kann dann zwischengespeicherte oder auf der Festplatte gespeicherte Inhalte in einen Socket schreiben, ohne dass ein Kontextwechsel in den Benutzerbereich erfolgt. Dadurch wird das Schreiben extrem schnell und verbraucht weniger CPU-Zyklen. Beachten Sie jedoch, dass mit sendfile() kopierte Daten den Benutzerbereich umgehen und daher nicht der regulären NGINX-Verarbeitungskette und den Filtern unterliegen, die Inhalte ändern (wie etwa gzip ). Wenn ein Konfigurationskontext sowohl die Sendfile- Direktive als auch Direktiven enthält, die einen Inhaltsänderungsfilter aktivieren, deaktiviert NGINX Sendfile automatisch für diesen Kontext.

Grenzen

Sie können verschiedene Grenzwerte festlegen, die dazu beitragen, dass Clients nicht zu viele Ressourcen verbrauchen, was sich negativ auf die Leistung Ihres Systems sowie auf die Sicherheit und das Benutzererlebnis auswirken kann. Im Folgenden sind einige der relevanten Richtlinien aufgeführt:

• limit_conn und limit_conn_zone – Begrenzen Sie die Anzahl der Client-Verbindungen, die NGINX akzeptiert, beispielsweise von einer einzelnen IP-Adresse. Durch ihre Festlegung können Sie verhindern, dass einzelne Clients zu viele Verbindungen öffnen und mehr Ressourcen verbrauchen, als ihnen zusteht.
• limit_rate – Begrenzt die Rate, mit der Antworten pro Verbindung an einen Client übertragen werden (damit Clients, die mehrere Verbindungen öffnen, diese Bandbreite für jede Verbindung nutzen können). Durch das Festlegen eines Grenzwertes kann eine Überlastung des Systems durch bestimmte Clients verhindert und eine gleichmäßigere Servicequalität für alle Clients sichergestellt werden.
• limit_req und limit_req_zone – Begrenzen Sie die Rate der von NGINX verarbeiteten Anfragen. Dies hat dieselben Vorteile wie das Festlegen von limit_rate . Sie können außerdem die Sicherheit insbesondere bei Anmeldeseiten verbessern, indem sie die Anforderungsrate auf einen Wert begrenzen, der für menschliche Benutzer angemessen, für Programme jedoch zu langsam ist, die versuchen, Ihre Anwendung mit Anforderungen zu überlasten (z. B. Bots bei einem DDoS-Angriff ).
• Parameter max_conns für die Serverdirektive in einem Upstream- Konfigurationsblock – Legt die maximale Anzahl gleichzeitiger Verbindungen fest, die von einem Server in einer Upstream-Gruppe akzeptiert werden. Durch die Festlegung einer Begrenzung können Sie eine Überlastung der Upstream-Server verhindern. Wenn Sie den Wert auf 0 (Null, Standard) setzen, bedeutet dies, dass keine Begrenzung vorhanden ist.
• Warteschlange (NGINX Plus) – Erstellt eine Warteschlange, in die Anfragen gestellt werden, wenn alle verfügbaren Server in der Upstream-Gruppe ihr Max_Conns- Limit erreicht haben. Diese Anweisung legt die maximale Anzahl von Anforderungen in der Warteschlange und optional die maximale Wartezeit (standardmäßig 60 Sekunden) fest, bevor ein Fehler zurückgegeben wird. Wenn Sie diese Anweisung weglassen, werden Anfragen nicht in die Warteschlange gestellt.

Caching und Komprimierung können die Leistung verbessern

Einige Zusatzfeatures von NGINX, mit denen sich die Performance einer Webanwendung steigern lässt, fallen zwar nicht wirklich unter den Begriff Tuning, sind aber dennoch erwähnenswert, da ihre Auswirkungen erheblich sein können. Hierzu gehören Caching und Komprimierung.

Zwischenspeicherung

Durch die Aktivierung des Caching auf einer NGINX-Instanz, die den Lastenausgleich für eine Reihe von Web- oder Anwendungsservern durchführt, können Sie die Reaktionszeit für Clients erheblich verbessern und gleichzeitig die Belastung der Backend-Server drastisch reduzieren. Caching ist ein eigenständiges Thema und wir werden hier nicht versuchen, darauf einzugehen. Siehe das NGINX Plus-Administratorhandbuch .

Kompression

Durch das Komprimieren der an Clients gesendeten Antworten kann deren Größe erheblich reduziert werden, sodass sie weniger Netzwerkbandbreite verbrauchen. Da das Komprimieren von Daten jedoch CPU-Ressourcen verbraucht, ist es besonders dann sinnvoll, wenn sich die Reduzierung der Bandbreitennutzung wirklich lohnt. Beachten Sie, dass Sie die Komprimierung nicht für Objekte aktivieren sollten, die bereits komprimiert sind, wie zum Beispiel JPEG-Dateien. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch .

Weitere Informationen finden Sie unter:

• Benchmarking von NGINX: Bessere Genauigkeit und aussagekräftige Ergebnisse (On-Demand-Webinar)
• NGINX-Referenzdokumentation unter nginx.org
• Vergleichen Sie NGINX-Modelle
• Technische Daten zu NGINX Plus

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns für eine Demo.