Nginx-HTTP-Verarbeitungsablauf: Konfigurationsoptimierung

Die Standardkonfiguration von Nginx ist auf Kompatibilität ausgelegt, nicht auf Leistung. Mit der richtigen Optimierung kann ein einzelner Server 50.000 bis 80.000 Anfragen pro Sekunde verarbeiten. Dieser Leitfaden behandelt die wichtigsten Einstellungen: Worker-Prozesse, Verbindungen, Keepalive, Pufferung, Lastenausgleich und wie Sie Ihre Änderungen mit Benchmarks überprüfen können.

Wie Nginx HTTP-Anfragen verarbeitet

Nginx verarbeitet Anfragen in verschiedenen Phasen, die jeweils Systemressourcen beanspruchen. Das Verständnis des Ablaufs hilft Ihnen dabei, die richtigen Einstellungen zu wählen.

Es beginnt auf Kernel-Ebene. Eingehende Verbindungen landen in SYN- und ACCEPT-Warteschlangen und werden von Nginx-Worker-Prozessen abgeholt. Nach der Annahme analysiert der Worker die HTTP-Anfrage aus dem Kernel-Puffer. TLS-Verkehr macht diesen Schritt rechenintensiver.

Als Nächstes ordnet Nginx die Anfrage anhand des Host-Headers und der IP/Port-Kombination einem virtuellen Server zu und löst die URI dann über Präfix- oder Regex-Abgleich in einen Standortblock auf.

Bei dynamischen Inhalten leitet Nginx die Anfrage an ein Backend (FastCGI, Proxy) weiter. Diese Upstream-Kommunikationsphase profitiert stark von persistenten Verbindungen. Ohne Upstream-Keepalive öffnet Nginx pro Anfrage eine neue TCP-Verbindung, was zu Latenz und CPU-Overhead führt.

Wenn proxy_buffering aktiviert ist, liest Nginx die gesamte Upstream-Antwort in den Speicher, bevor sie an den Client übermittelt wird. Dadurch wird der Worker entlastet und kann neue Anfragen sofort bearbeiten. Schließlich ermöglicht die Aktivierung von sendfile Zero-Copy-Übertragungen, wodurch der Durchsatz von etwa 6 Gbit/s auf 30 Gbit/s gesteigert werden kann.

Jede Phase beansprucht Speicherpuffer, Dateideskriptoren und CPU-Zyklen. Die folgenden Abschnitte befassen sich mit den einzelnen Engpässen.

Worker-Prozesse und Verbindungen

Beginnen Sie mit worker_processes auto; in Ihrem Hauptkontext. Dies passt die Anzahl der Worker an Ihre CPU-Kerne an. Auf einem VPS mit begrenzter Kernanzahl stellen Sie die Anzahl manuell ein (z. B. worker_processes 2;). Wenn Ihre Arbeitslast speicherintensiv ist, sollten Sie erwägen, die Anzahl der Worker zu reduzieren, um eine Überlastung des Arbeitsspeichers zu vermeiden.

Aktivieren Sie worker_cpu_affinity auto; , um jeden Worker an einen bestimmten Kern zu binden. Dies reduziert Cache-Fehler und Kontextwechsel. Verfügbar seit Nginx 1.9.10.

Verbindungslimits

Die worker_connections Direktive legt fest, wie viele gleichzeitige Verbindungen jeder Worker verarbeiten kann. Die Gesamtkapazität beträgt worker_processes × worker_connections. Der Standardwert von 512 oder 1.024 ist für den Produktivbetrieb zu niedrig. Setzen Sie ihn für stark frequentierte Websites auf 2.048 oder 4.096 pro Worker.

Jede Verbindung benötigt mindestens einen Dateideskriptor. In einer Reverse-Proxy-Konfiguration verwendet jede Verbindung zwei (einen für den Client, einen für den Upstream). Setzen Sie worker_rlimit_nofile den Wert auf mindestens das Doppelte Ihres worker_connections Wert mit einem gewissen Spielraum ein. Für worker_connections 4096;verwenden Sie worker_rlimit_nofile 10000; oder höher.

Erhöhen Sie auf Systemebene fs.file-max in /etc/sysctl.conf auf mindestens 500.000 und stellen Sie systemds LimitNOFILE=65535.

Fügen Sie schließlich multi_accept on; im events-Block hinzu, damit die Worker alle anstehenden Verbindungen auf einmal annehmen, anstatt jeweils nur eine.

Timeouts und Keepalive

Client-Keepalive

Die keepalive_timeout Steuert, wie lange inaktive Client-Verbindungen offen bleiben. Für Server mit hohem Datenverkehr sind 30 bis 65 Sekunden gut geeignet. Verwenden Sie die Form mit zwei Parametern:

keepalive_timeout 65s 60s;

Der erste Wert ist das serverseitige Timeout. Der zweite sendet einen Keep-Alive: timeout=60 Header an den Client. Wenn der Client-Wert etwas niedriger eingestellt wird, verhindert dies Race-Conditions, bei denen Browser versuchen, Verbindungen wiederzuverwenden, die Nginx bereits geschlossen hat.

Die keepalive_requests Direktive begrenzt die Anzahl der Anfragen, die eine einzelne Verbindung verarbeitet, bevor sie geschlossen wird. Der Standardwert ist 1.000 (erhöht von 100 in Version 1.19.10). Bei stabilen Backends sollten Sie diesen Wert auf 10.000 erhöhen, um die Verbindungsfluktuation zu verringern.

Proxy-Timeouts

proxy_connect_timeout legt fest, wie lange Nginx wartet, um eine Verbindung zum Backend herzustellen. Der Standardwert beträgt 60 Sekunden. Reduzieren Sie ihn auf 5 bis 10 Sekunden für ein schnelles Failover.

proxy_read_timeout Legt fest, wie lange Nginx zwischen aufeinanderfolgenden Lesevorgängen vom Upstream wartet. Passen Sie diesen Wert an das Ausführungszeitlimit Ihres Backends an. Wenn das von PHP-FPM request_terminate_timeout 120 Sekunden beträgt, stellen Sie proxy_read_timeout auf mindestens 120 Sekunden, um vorzeitige 504-Fehler zu vermeiden.

proxy_send_timeout steuert das Intervall zwischen aufeinanderfolgenden Schreibvorgängen an den Upstream. Der Standardwert von 60 Sekunden ist in der Regel ausreichend, es sei denn, Sie senden große Request-Body-Daten.

In der Regel proxy_connect_timeout sollte immer der kürzeste der drei Werte sein.

Puffergröße

client_body_buffer_size steuert, wie viel vom Body einer eingehenden Anfrage Nginx im Speicher hält. Der Standardwert von 8k oder 16k reicht für einfache Formularübermittlungen aus, aber Datei-Uploads werden auf die Festplatte ausgelagert. Erhöhen Sie den Wert auf 128k für kleine bis mittlere Uploads. Erhöhen Sie client_max_body_size den Standardwert von 1 MB, wenn Benutzer größere Dateien hochladen.

proxy_buffer_size behandelt Antwort-Header getrennt vom Hauptteil. Der Standardwert von 4 KB oder 8 KB funktioniert in der Regel, aber Anwendungen mit großen Set-Cookie Headern (im E-Commerce üblich) können diesen Wert überschreiten, was zu 502-Fehlern führt. Messen Sie Ihre tatsächliche Header-Größe:

curl -s -w '%{size_header}' -o /dev/null http://your-upstream-url

Runden Sie auf das nächste 4k-Vielfache auf.

proxy_buffers Legt die Anzahl und Größe der Puffer für den Antworttext fest. Der Standardwert (8 Puffer à 4 KB oder 8 KB, insgesamt 32 KB bis 64 KB) reicht für eine große JSON-Antwort nicht aus. Messen Sie Ihre größte typische Antwort mit curl und konfigurieren Sie genügend Puffer, um sie vollständig im RAM zu halten.

Verhalten der Proxy-Pufferung

Bei proxy_buffering on (Standard) liest Nginx die gesamte Upstream-Antwort in den Speicher, bevor sie an den Client gesendet wird. Dadurch können Backend-Server sofort mit neuen Anfragen fortfahren.

Stellen Sie proxy_busy_buffers_size auf mindestens proxy_buffer_size plus einen Puffer, jedoch weniger als Ihren gesamten Pufferpool. Bei proxy_buffers 8 16k (insgesamt 128k) sollte proxy_busy_buffers_size unter 112k.

Deaktivieren Sie für Echtzeit-Endpunkte wie Server-Sent Events oder Long-Polling die Pufferung proxy_buffering off in einem ortsspezifischen Block. Wenden Sie dies selektiv auf /stream bestimmte Pfade /events Pfade an, nicht global.

Lastenausgleich und Upstream-Keepalive

Standardmäßig öffnet Nginx für jede zwischengespeicherte Anfrage eine neue TCP-Verbindung. Jeder Handshake verursacht eine Latenz von 10 bis 100 ms, wobei TLS weitere 10 bis 50 ms hinzufügt. Upstream Keepalive unterhält einen Pool persistenter Verbindungen, um diesen Overhead zu beseitigen.

Drei Einstellungen sind erforderlich:

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 128;
}
 
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Der keepalive Wert legt die maximale Anzahl inaktiver Verbindungen pro Worker fest. Berechnen Sie die optimale Poolgröße wie folgt: (workers × target concurrency) / upstream nodes.

Stellen Sie Upstream keepalive_timeout auf 60 bis 120 Sekunden ein, um es an die Einstellungen Ihres Backends anzupassen und Traffic-Spitzen zu bewältigen.

Lastverteilungsstrategien

Nginx unterstützt mehrere Lastverteilungsmethoden. Round-Robin (die Standardeinstellung) verteilt Anfragen sequenziell. least_conn leitet Anfragen an den Server mit den wenigsten aktiven Verbindungen weiter, was sich für Workloads mit variablen Anfragedauern eignet. ip_hash bietet Sitzungspersistenz, indem dieselbe Client-IP an dasselbe Backend weitergeleitet wird.

Verwenden Sie den weight Parameter, wenn Server unterschiedliche Kapazitäten haben:

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

Der gewichtete Server erhält das Dreifache des Datenverkehrs. Der backup Server wird nur aktiviert, wenn alle primären Server ausgefallen sind. Konfigurieren max_fails und fail_timeout für passive Zustandsprüfungen und verwenden Sie max_conns , um die Anzahl der gleichzeitigen Verbindungen pro Backend zu begrenzen.

Testen und Überwachen

Messen Sie immer die Ausgangsleistung, bevor Sie Änderungen vornehmen. Führen Sie nach jeder Änderung erneut einen Benchmark durch. Nehmen Sie jeweils nur eine Änderung vor.

Überprüfen Sie die Syntax Ihrer Konfiguration mit nginx -t , bevor Sie die Seite neu laden. Führen Sie Benchmarks von einem separaten Rechner aus, um Ressourcenkonflikte zu vermeiden.

wrk ist das Standardwerkzeug für HTTP-Lasttests:

wrk -t4 -c200 -d30s http://your-server.com/

Erfassen Sie die Anzahl der Anfragen pro Sekunde, die durchschnittliche Latenz, die maximale Latenz und die Übertragungsrate. Apache Bench eignet sich für einfachere Tests:

ab -n 50000 -c 40 http://your-server.com/

Laufende Überwachung

Aktivieren Sie das stub_status Modul, um aktive Verbindungen in Echtzeit über curl http://localhost/nginx_status.

Fügen Sie Ihrem Protokollformat Zeitvariablen hinzu, um festzustellen, wo Verzögerungen auftreten:

• $request_time für die Gesamtdauer der Anfrage
• $upstream_connect_time für die Backend-Verbindungszeit
• $upstream_response_time für die gesamte Backend-Verarbeitungszeit

Überprüfen Sie die Fehlerprotokolle auf Pufferprobleme mit journalctl -u nginx --no-pager | grep "temporary file". Wenn Antworten auf die Festplatte geschrieben werden, ist Ihr proxy_buffers zu klein. Achten Sie auf Fehler wie „zu viele geöffnete Dateien“, die darauf hinweisen, worker_rlimit_nofile erhöht werden müssen.

Reduzieren Sie die Protokoll-E/A durch gepufferte Protokollierung:

access_log /var/log/nginx/access.log combined buffer=64k flush=5s;

Verwenden Sie ss -tn state established dst [backend_ip] bei Lasttests, um zu überprüfen, ob Verbindungen wiederverwendet werden und sich nicht im TIME_WAIT-Zustand stauen.

Für dedizierte Server und VPS-Hosting, die für hochleistungsfähige Workloads optimiert sind, siehe FDC-Server.