Nginx Performance-Optimierung: Tipps für schnellere Websites

Langsame Websites haben meist eine Handvoll Ursachen: teure Upstream-Antworten, fehlende Cache-Header, überdimensionierte Assets, blockierte Worker oder ein Server, der auf Standardwerte statt auf Ihren Traffic abgestimmt ist. Die Nginx-Leistungsoptimierung funktioniert am besten, wenn Sie zuerst messen, jeweils nur eine Einstellung ändern und die Konfiguration lesbar halten.

Verwenden Sie die folgenden Beispiele als Ausgangspunkt und testen Sie sie dann mit Lasttests gegen Ihre eigene Anwendung. Ein statischer Dateiserver, eine WordPress/PHP-FPM-Site und ein API-Reverse-Proxy erfordern unterschiedliche Kompromisse.

Verständnis von Nginx-Leistungsengpässen

Finden Sie zunächst den Engpass. Häufige Ursachen sind:

• CPU-Auslastung: Hohe CPU-Last verlangsamt die Anfragebearbeitung, Komprimierung und TLS-Arbeit.
• Speicherdruck: Swapping beeinträchtigt die Latenz erheblich.
• Netzwerk-I/O: Langsame Verbindungen, kleine Upstream-Fenster oder Paketverluste können die Antwortzeit dominieren.
• Festplatten-I/O: Statische Dateien, Cache-Dateien und Logs greifen immer noch auf den Speicher zu.
• Upstream-Latenz: Nginx kann schnell sein, während Ihr Anwendungsserver langsam ist.

Tools wie top, htop, iostat, ss, Zugriffslogs und das Nginx-stub_status-Modul können Ihnen helfen zu entscheiden, was optimiert werden soll.

Kern-Techniken zur Nginx-Optimierung

Worker-Prozesse und Verbindungen

Die Direktive worker_processes steuert, wie viele Worker-Prozesse Nginx startet. auto ist ein praktischer Standard, da Nginx die verfügbaren CPU-Kerne erkennt.

# Setzen Sie worker_processes auf die Anzahl der CPU-Kerne
worker_processes auto;

Innerhalb jedes Worker-Prozesses begrenzt worker_connections, wie viele gleichzeitige Verbindungen dieser Worker öffnen kann. Die grobe Obergrenze ist worker_processes * worker_connections, aber die tatsächliche Kapazität hängt auch von Upstream-Verbindungen, Dateideskriptor-Limits, Keep-Alive-Verhalten und Betriebssystemgrenzen ab.

# Erhöhen Sie worker_connections für stark frequentierte Websites
worker_connections 1024;

Wenn Sie Too many open files sehen, reicht es nicht, nur worker_connections zu erhöhen. Überprüfen Sie auch das Dateideskriptor-Limit des Dienstes, das oft durch systemd LimitNOFILE oder Shell-Limits gesteuert wird.

Caching-Strategien

Caching ist in der Regel die Optimierung mit der größten Auswirkung auf die Nginx-Leistung, da es wiederholte Arbeit verhindert.

Browser-Caching

Weisen Sie Browser an, versionierte statische Assets wie Bilder, CSS und JavaScript zu cachen. Verwenden Sie lange Lebensdauern nur, wenn sich Dateinamen bei der Bereitstellung ändern, z. B. app.8f3c1.css.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Proxy-Caching

Wenn Nginx ein Reverse-Proxy ist, kann es ausgewählte Backend-Antworten cachen. Dies funktioniert gut für öffentliche Seiten, API-Antworten mit klaren Frischeregeln und teure Seiten, die nicht pro Benutzer variieren.

Definieren Sie zunächst eine Cache-Zone im http-Block:

http {
    # ... andere http-Konfigurationen ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
    # ...
}

• /var/cache/nginx: Das Verzeichnis, in dem Cache-Dateien gespeichert werden.
• levels=1:2: Definiert die Verzeichnisstruktur für den Cache.
• keys_zone=my_cache:10m: Erstellt eine gemeinsame Speicherzone namens my_cache mit 10 MB Größe zum Speichern von Cache-Schlüsseln.
• max_size=1g: Legt die maximale Größe des Caches fest.
• inactive=60m: Entfernt Cache-Einträge, die 60 Minuten lang nicht aufgerufen wurden.

Aktivieren Sie dann das Caching in Ihrem location-Block:

location / {
    proxy_pass http://your_backend_app;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m; # Cache 200 und 302 Antworten für 10 Minuten
    proxy_cache_valid 404 1m;     # Cache 404 Antworten für 1 Minute
    add_header X-Cache-Status $upstream_cache_status;
}

add_header X-Cache-Status $upstream_cache_status; ist nützlich für das Debugging und zeigt an, ob eine Anfrage ein Cache-Treffer, -Fehlschlag oder -Umgehung war.

Cachen Sie keine personalisierten Seiten, es sei denn, Ihr Cache-Schlüssel berücksichtigt die Daten, die die Antwort ändern. Ein Dashboard für angemeldete Benutzer sollte beispielsweise in der Regel den Proxy-Cache umgehen, während /assets/logo.png lange gecacht werden kann.

Komprimierung

Komprimierung reduziert die Übertragungsgröße für textbasierte Antworten wie HTML, CSS, JavaScript, JSON und XML. Sie hilft bei bereits komprimierten Dateien wie JPEG, PNG, MP4 oder vielen Archivformaten nicht viel.

http {
    # ...
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

• gzip on;: Aktiviert die Gzip-Komprimierung.
• gzip_vary on;: Fügt den Vary: Accept-Encoding-Header hinzu, der für Caching-Proxys wichtig ist.
• gzip_proxied any;: Komprimiert auch Antworten für Proxy-Anfragen.
• gzip_comp_level 6;: Legt die Komprimierungsstufe fest (1-9, höher bedeutet bessere Komprimierung, aber mehr CPU).
• gzip_types ...;: Gibt die zu komprimierenden MIME-Typen an.

Brotli kann Text-Assets gut komprimieren, aber standardmäßige Open-Source-Nginx-Builds unterstützen nicht alle Brotli. Überprüfen Sie Ihr Paket oder Modul-Set, bevor Sie Brotli-Direktiven hinzufügen.

Verbindungsverwaltung und Keep-Alive

Die Direktive keepalive_timeout steuert, wie lange eine untätige Client-Verbindung offen bleibt. Die Wiederverwendung einer Verbindung vermeidet zusätzliche TCP- und TLS-Handshakes, aber untätige Verbindungen verbrauchen weiterhin Ressourcen.

http {
    # ...
    keepalive_timeout 65;
    keepalive_requests 1000;
    # ...
}

• keepalive_timeout 65;: Setzt das Keep-Alive-Timeout auf 65 Sekunden.
• keepalive_requests 1000;: Legt die maximale Anzahl von Anfragen fest, die über eine einzige Keep-Alive-Verbindung gestellt werden können.

Für APIs mit vielen kurzen Anfragen hilft Keep-Alive. Für einen kleinen Server mit vielen untätigen Clients kann ein kürzeres Timeout besser sein.

Pufferung und Anfragegrößenbeschränkungen

Nginx verwendet Puffer für Client-Bodies und Proxy-Antworten. Die Standardwerte sind für viele Websites in Ordnung, aber Upload-lastige Apps und große Upstream-Header können explizite Einstellungen erfordern.

http {
    # ...
    client_body_buffer_size 10K;
    client_max_body_size 8M;
    proxy_buffers 8 16k;
    proxy_buffer_size 16k;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
    # ...
}

• client_body_buffer_size: Größe des Puffers, der zum Lesen des Client-Anfrage-Bodys verwendet wird.
• client_max_body_size: Maximal zulässige Größe des Client-Anfrage-Bodys.
• proxy_buffers, proxy_buffer_size: Steuern die Pufferung, wenn Nginx als Proxy fungiert.

Vermeiden Sie es, Puffer-Schnipsel blind zu kopieren. Wenn Sie upstream sent too big header sehen, untersuchen Sie die Upstream-Header, bevor Sie proxy_buffer_size erhöhen. Wenn Uploads mit 413 Request Entity Too Large fehlschlagen, setzen Sie client_max_body_size auf die Größe, die Ihre App tatsächlich unterstützt.

TLS-Optimierung

Für HTTPS-Websites beeinflussen TLS-Einstellungen sowohl die Latenz als auch die Sicherheit.

• Sitzungswiederaufnahme: Verwenden Sie einen Sitzungscache, um wiederholte Verbindungen zu beschleunigen.

  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;
  ssl_session_tickets off;
  

• TLS-Versionen: Aktivieren Sie TLS 1.2 und TLS 1.3, sofern Ihre Kompatibilitätsanforderungen nichts anderes vorgeben.
• OCSP-Stapling: Kann Zertifikatsvalidierungs-Roundtrips reduzieren, wenn Ihre Zertifikatskette dies unterstützt.

  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.8.8 8.8.4.4 valid=300s;
  

Statische Dateibereitstellung

Nginx ist stark in der Bereitstellung statischer Dateien. Diese Direktiven sind im http-Block üblich:

• sendfile: Ermöglicht dem Kernel, Dateidaten auf unterstützten Systemen direkt an den Socket zu kopieren.

  sendfile on;
  

• tcp_nopush und tcp_nodelay: Optimieren das Paketversandverhalten für typische HTTP-Workloads.

  tcp_nopush on;
  tcp_nodelay on;
  

Überwachung und Tests

Testen und vergleichen Sie nach jeder Änderung. Nützliche Tools sind:

• Nginx stub_status: Aktive Verbindungen, akzeptierte Verbindungen, bearbeitete Verbindungen und Anfragen.
• top/htop: CPU- und Speicherauslastung.
• iostat: Festplatten-I/O.
• WebPageTest oder PageSpeed Insights: Clientseitige Leistung.
• wrk, ab oder hey: Lokale Lasttests gegen kontrollierte Endpunkte.

Behalten Sie eine Kopie der vorherigen Konfiguration, führen Sie sudo nginx -t aus, laden Sie neu und vergleichen Sie Latenz, Fehlerrate, CPU und Upstream-Antwortzeit. Die beste Nginx-Leistungsoptimierung ist die, die Ihre Messungen beweisen können.

Praktische Zusammenfassung

Beginnen Sie mit Messungen und beheben Sie dann zuerst den größten Engpass. Für die meisten Websites bedeutet dies, sinnvolle Worker-Limits zu setzen, Browser-Caching für statische Assets hinzuzufügen, Gzip zu aktivieren, sichere Upstream-Antworten zu cachen und nach jedem Neuladen die Logs zu überwachen.