NGINX für mehr Leistung optimieren

NGINX | 10. Oktober 2014

Rick NelsonRegional Vice President, Solution Engineering

NGINX ist weithin als leistungsstarker Load Balancer, Cache, und Webserver bekannt und unterstützt über 40 % der meistbesuchten Websites weltweit. Für die meisten Anwendungsfälle eignen sich die Standardeinstellungen von NGINX und Linux gut. Um eine optimale Leistung zu erzielen, sind jedoch manchmal einige Anpassungen erforderlich. In diesem Blogbeitrag werden einige der NGINX- und Linux-Einstellungen erläutert, die bei der Optimierung eines Systems berücksichtigt werden sollten.

Sie können nahezu jede Einstellung optimieren. Dieser Beitrag konzentriert sich jedoch auf die wenigen Einstellungen, deren Optimierung den meisten Nutzern zugutekommt. Einige Einstellungen sollten Sie unserer Empfehlung nach nur ändern, wenn Sie über fundierte Kenntnisse von NGINX und Linux verfügen oder von unseren Teams für Support oder Professional Services dazu angewiesen werden. Auf diese Einstellungen gehen wir hier nicht ein. Das Professional-Services-Team hat bereits mit einigen der meistbesuchten Websites der Welt zusammengearbeitet, um NGINX auf maximale Leistung zu optimieren. Es unterstützt auch Sie gerne dabei, das Potenzial Ihrer NGINX- oder NGINX Plus-Bereitstellung voll auszuschöpfen.

Einleitung

Grundlegende Kenntnisse der NGINX-Architektur und der Konfigurationskonzepte werden vorausgesetzt. Dieser Beitrag soll nicht die NGINX-Dokumentation wiederholen, sondern bietet einen Überblick über die verschiedenen Optionen und enthält Links zur entsprechenden Dokumentation.

Eine gute Faustregel bei der Optimierung ist, jeweils nur eine Einstellung zu ändern und sie auf den Standardwert zurückzusetzen, wenn die Änderung keine Leistungsverbesserung bewirkt.

Wir beginnen mit einer Erläuterung der Linux-Optimierung, da die Werte einiger Betriebssystemeinstellungen bestimmen, wie Sie Ihre NGINX-Konfiguration optimieren.

Optimieren Ihrer Linux-Konfiguration

Die Einstellungen moderner Linux-Kernel (2.6+) sind für die meisten Anwendungsfälle geeignet. Es kann jedoch sinnvoll sein, einige davon anzupassen. Prüfen Sie das Kernel-Protokoll auf Fehlermeldungen, die darauf hinweisen, dass ein Wert zu niedrig eingestellt ist, und passen Sie ihn entsprechend den Empfehlungen an. Hier behandeln wir nur die Einstellungen, bei denen eine Optimierung unter normalen Arbeitslasten am ehesten Vorteile bringt. Einzelheiten zur Anpassung dieser Einstellungen finden Sie in Ihrer Linux-Dokumentation.

Die Backlog-Warteschlange

Die folgenden Einstellungen betreffen Verbindungen und deren Einreihung in die Warteschlange. Wenn sehr viele Verbindungen eingehen und die Leistung ungleichmäßig ist (beispielsweise weil einige Verbindungen ins Stocken zu geraten scheinen), kann es helfen, diese Einstellungen zu ändern.

net.core.somaxconn – Die maximale Anzahl von Verbindungen, die zur Annahme durch NGINX in die Warteschlange gestellt werden können. Der Standardwert ist häufig sehr niedrig, was in der Regel kein Problem darstellt, da NGINX Verbindungen sehr schnell annimmt. Bei hohem Datenverkehr auf Ihrer Website kann es sich jedoch lohnen, diesen Wert zu erhöhen. Wenn Fehlermeldungen im Kernel-Protokoll darauf hinweisen, dass der Wert zu niedrig ist, erhöhen Sie ihn so lange, bis keine Fehler mehr auftreten.Hinweis: Wenn Sie diesen Wert auf mehr als 512 setzen, passen Sie den Parameter backlog der NGINX-Direktive listen entsprechend an.
net.core.netdev_max_backlog – Die Rate, mit der Pakete von der Netzwerkkarte zwischengespeichert werden, bevor sie an die CPU weitergeleitet werden. Eine Erhöhung des Werts kann die Leistung auf Systemen mit hoher Bandbreite verbessern. Prüfen Sie das Kernel-Protokoll auf Fehler im Zusammenhang mit dieser Einstellung und ziehen Sie die Dokumentation der Netzwerkkarte zurate, um Hinweise zur Änderung des Werts zu erhalten.

Dateideskriptoren

Dateideskriptoren sind Betriebssystemressourcen, die unter anderem zur Darstellung von Verbindungen und geöffneten Dateien verwendet werden. NGINX kann bis zu zwei Dateideskriptoren pro Verbindung verwenden. Wenn NGINX beispielsweise als Proxy fungiert, verwendet es in der Regel einen Dateideskriptor für die Clientverbindung und einen weiteren für die Verbindung zum Proxyserver. Bei Verwendung von HTTP-Keep-Alive-Verbindungen ist dieses Verhältnis jedoch deutlich niedriger. Bei einem System, das eine große Anzahl von Verbindungen verarbeitet, müssen möglicherweise die folgenden Einstellungen angepasst werden:

sys.fs.file-max – Die systemweite Obergrenze für Dateideskriptoren
nofile – Das benutzerspezifische Limit für Dateideskriptoren, das in der Datei /etc/security/limits.conf festgelegt wird

Ephemere Ports

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

net.ipv4.ip_local_port_range – Anfang und Ende des Bereichs der Portwerte. Wenn Sie feststellen, dass Ihnen die Ports ausgehen, vergrößern Sie den Bereich. Eine gängige Einstellung ist der Portbereich von 1024 bis 65000.

Optimieren Ihrer NGINX-Konfiguration

Im Folgenden finden Sie einige NGINX-Direktiven, die sich auf die Leistung auswirken können. Wie bereits erwähnt, behandeln wir nur Direktiven, die Sie bedenkenlos selbst anpassen können. Wir empfehlen, die Einstellungen anderer Direktiven nur nach Rücksprache mit dem NGINX-Team zu ändern.

Worker-Prozesse

NGINX kann mehrere Worker-Prozesse ausführen, die jeweils eine große Anzahl gleichzeitiger Verbindungen verarbeiten können. Mit den folgenden Direktiven können Sie die Anzahl der Worker-Prozesse und deren Umgang mit Verbindungen steuern:

worker_processes – Die Anzahl der NGINX-Worker-Prozesse (der Standardwert ist 1). In den meisten Fällen empfiehlt es sich, einen Worker-Prozess pro CPU-Kern auszuführen. Daher empfehlen wir, diese Direktive auf auto zu setzen. In manchen Fällen kann es sinnvoll sein, diese Anzahl zu erhöhen, etwa wenn die Worker-Prozesse viele Festplatten-E/A-Vorgänge ausführen müssen.
worker_connections – Die maximale Anzahl an Verbindungen, die jeder Worker-Prozess gleichzeitig verarbeiten kann. Der Standardwert ist 512, aber die meisten Systeme verfügen über genügend Ressourcen, um eine größere Anzahl 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, da sie den CPU- und Netzwerkaufwand für das Öffnen und Schließen von Verbindungen reduzieren. NGINX beendet alle Clientverbindungen und stellt separate, unabhängige Verbindungen zu den Upstream-Servern her. NGINX unterstützt Keepalive-Verbindungen sowohl für Clients als auch für Upstream-Server. Die folgenden Direktiven beziehen sich auf Client-Keepalive-Verbindungen:

keepalive_requests – Die Anzahl der Anfragen, die ein Client über eine einzelne Keepalive-Verbindung stellen kann. Der Standardwert ist 100, aber ein deutlich höherer Wert kann insbesondere für Tests mit einem Lastgenerierungstool nützlich sein, das in der Regel eine große Anzahl von Anfragen von einem einzelnen Client sendet.
keepalive_timeout – Gibt an, wie lange eine inaktive Keepalive-Verbindung geöffnet bleibt.

Die folgende Direktive bezieht sich auf Keepalive-Verbindungen zu Upstream-Servern:

keepalive – Die Anzahl der inaktiven Keepalive-Verbindungen zu einem Upstream-Server, die für jeden Worker-Prozess geöffnet bleiben. Es gibt keinen Standardwert.

Um Keepalive-Verbindungen zu Upstream-Servern zu aktivieren, müssen Sie außerdem die folgenden Direktiven in die Konfiguration aufnehmen:

proxy_http_version 1.1;proxy_set_header Connection "";

Zugriffsprotokollierung

Die Protokollierung jeder Anfrage beansprucht sowohl CPU- als auch E/A-Ressourcen. Eine Möglichkeit, diese Belastung zu reduzieren, besteht darin, die Pufferung des Zugriffsprotokolls zu aktivieren. Dadurch führt NGINX nicht für jeden Protokolleintrag einen separaten Schreibvorgang aus, sondern sammelt mehrere Einträge in einem Puffer und schreibt sie gemeinsam in einem einzigen Vorgang in die Datei.

Um die Pufferung des Zugriffsprotokolls zu aktivieren, fügen Sie der Direktive buffer=size den Parameter access_log hinzu. NGINX schreibt den Inhalt des Puffers in das Protokoll, sobald der Puffer den Wert size erreicht. Damit NGINX den Puffer nach einer bestimmten Zeitspanne schreibt, fügen Sie den Parameter flush=time hinzu. Wenn beide Parameter festgelegt sind, schreibt NGINX die Einträge in die Protokolldatei, sobald der nächste Protokolleintrag nicht mehr in den Puffer passt beziehungsweise die Einträge im Puffer älter als die angegebene Zeitspanne sind. Protokolleinträge werden auch geschrieben, wenn ein Worker-Prozess seine Protokolldateien erneut öffnet oder heruntergefahren wird. Um die Zugriffsprotokollierung vollständig zu deaktivieren, fügen Sie der Direktive off den Parameter access_log hinzu.

Sendfile

Der Systemaufruf sendfile() des Betriebssystems kopiert Daten von einem Dateideskriptor in einen anderen und ermöglicht dabei häufig Zero-Copy, wodurch TCP-Datenübertragungen beschleunigt werden können. Damit NGINX diesen Systemaufruf verwenden kann, fügen Sie die Direktive sendfile in den Kontext http oder in einen server- bzw. location-Kontext ein. NGINX kann dann zwischengespeicherte oder auf dem Datenträger befindliche Inhalte über einen Socket senden, ohne in den Benutzerbereich wechseln zu müssen. Dadurch erfolgt der Schreibvorgang äußerst schnell und benötigt weniger CPU-Zyklen. Beachten Sie jedoch, dass mit sendfile() kopierte Daten den Benutzerbereich umgehen und daher weder die reguläre Verarbeitungskette von NGINX noch inhaltsverändernde Filter wie gzip durchlaufen. Wenn ein Konfigurationskontext sowohl die Direktive sendfile als auch Direktiven enthält, die einen inhaltsverändernden Filter aktivieren, deaktiviert NGINX sendfile für diesen Kontext automatisch.

Grenzwerte

Sie können verschiedene Grenzwerte festlegen, um zu verhindern, dass Clients zu viele Ressourcen verbrauchen. Dies könnte sich negativ auf die Leistung und Sicherheit Ihres Systems sowie auf die Benutzerfreundlichkeit auswirken. Im Folgenden finden Sie einige der relevanten Direktiven:

limit_conn und limit_conn_zone – Begrenzen die Anzahl der Clientverbindungen, die NGINX akzeptiert, beispielsweise von einer einzelnen IP-Adresse. Durch ihre Konfiguration lässt sich verhindern, dass einzelne Clients zu viele Verbindungen öffnen und mehr als den ihnen zustehenden Anteil an Ressourcen verbrauchen.
limit_rate – Begrenzt pro Verbindung die Übertragungsrate von Antworten an einen Client (Clients, die mehrere Verbindungen öffnen, können diese Bandbreite also für jede Verbindung nutzen). Durch das Festlegen eines Limits lässt sich verhindern, dass bestimmte Clients das System überlasten. Dadurch wird eine gleichmäßigere Dienstqualität für alle Clients gewährleistet.
limit_req und limit_req_zone – Begrenzen die Rate der von NGINX verarbeiteten Anfragen, was dieselben Vorteile bietet wie das Festlegen von limit_rate. Sie können außerdem die Sicherheit erhöhen, insbesondere bei Anmeldeseiten, indem sie die Anfragerate auf einen Wert begrenzen, der für menschliche Benutzer angemessen, für Programme, die Ihre Anwendung mit Anfragen überlasten wollen (z. B. Bots bei einem DDoS-Angriff), jedoch zu niedrig ist.
max_conns-Parameter der server-Direktive in einem upstream-Konfigurationsblock – Legt die maximale Anzahl gleichzeitiger Verbindungen fest, die von einem Server in einer Upstream-Gruppe akzeptiert werden. Durch das Festlegen eines Grenzwerts kann eine Überlastung der Upstream-Server verhindert werden. Der Wert 0 (null, die Standardeinstellung) bedeutet, dass es keine Begrenzung gibt.
queue (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 Direktive legt die maximale Anzahl von Anfragen in der Warteschlange und optional die maximale Wartezeit (standardmäßig 60 Sekunden) fest, bevor ein Fehler zurückgegeben wird. Wenn Sie diese Direktive weglassen, werden Anfragen nicht in eine Warteschlange gestellt.

Caching und Komprimierung können die Leistung verbessern

Einige zusätzliche Funktionen von NGINX, mit denen sich die Leistung einer Webanwendung steigern lässt, fallen zwar nicht wirklich unter die Kategorie Optimierung, sind aber dennoch erwähnenswert, da sie erhebliche Auswirkungen haben können. Dazu gehören Caching und Komprimierung.

Caching

Wenn Sie das Caching auf einer NGINX-Instanz aktivieren, die den Datenverkehr auf mehrere Web- oder Anwendungsserver verteilt, können Sie die Antwortzeiten für Clients erheblich verbessern und gleichzeitig die Last auf den Backend-Servern deutlich reduzieren. Caching ist ein eigenständiges Thema, auf das wir hier nicht näher eingehen. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch.

Komprimierung

Durch die Komprimierung der an Clients gesendeten Antworten lässt sich deren Größe erheblich reduzieren, sodass weniger Netzwerkbandbreite benötigt wird. Da die Datenkomprimierung jedoch CPU-Ressourcen beansprucht, ist sie vor allem dann sinnvoll, wenn sich die Reduzierung der Bandbreitennutzung wirklich lohnt. Beachten Sie, dass Sie die Komprimierung nicht für bereits komprimierte Objekte wie JPEG-Dateien aktivieren sollten. Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch.

Weitere Informationen finden Sie unter: