Wesentliche Checkliste zur Nginx-Leistungsoptimierung für Websites mit hohem Traffic

Für jede Website, die einen erheblichen Traffic verzeichnet, sticht Nginx als leistungsstarker und äußerst effizienter Webserver und Reverse-Proxy hervor. Die bloße Bereitstellung von Nginx reicht jedoch nicht aus, um unter hoher Last eine optimale Leistung zu gewährleisten. Eine ordnungsgemäße Konfiguration und Abstimmung sind entscheidend, um sein volles Potenzial auszuschöpfen und sicherzustellen, dass Ihre Webanwendungen schnell, reaktionsschnell und zuverlässig bleiben.

Dieser Artikel bietet eine umfassende Checkliste wichtiger Nginx-Konfigurationen und Direktiven, die speziell für die Leistungsoptimierung in Umgebungen mit hohem Traffic entwickelt wurden. Wir behandeln alles, von der Verwaltung von Worker-Prozessen und Verbindungen bis hin zur Feinabstimmung von Puffern, der Implementierung robuster Caching-Strategien und der Optimierung der Komprimierung. Durch die systematische Bearbeitung dieser Bereiche können Sie die Serverlast erheblich reduzieren, die Bereitstellungsgeschwindigkeit von Inhalten verbessern und das allgemeine Benutzererlebnis steigern.

1. Optimierung von Worker-Prozessen und Verbindungen

Nginx nutzt ein Master-Worker-Prozessmodell. Der Master-Prozess liest die Konfiguration und verwaltet die Worker-Prozesse, die die eigentlichen Client-Anfragen bearbeiten. Die richtige Konfiguration dieser Prozesse kann die Nebenläufigkeit und Ressourcennutzung drastisch verbessern.

worker_processes

Diese Direktive legt fest, wie viele Worker-Prozesse Nginx starten soll. Im Allgemeinen wird durch die Einstellung auf auto Nginx veranlasst, die Anzahl der CPU-Kerne zu erkennen und eine gleiche Anzahl von Worker-Prozessen zu starten, was eine gängige bewährte Methode ist.

worker_connections

Definiert die maximale Anzahl gleichzeitiger Verbindungen, die ein einzelner Worker-Prozess öffnen kann. Diese Einstellung bestimmt zusammen mit worker_processes die gesamte theoretische Anzahl gleichzeitiger Verbindungen, die Nginx verarbeiten kann (worker_processes * worker_connections).

multi_accept

Ermöglicht einem Worker-Prozess, mehrere neue Verbindungen auf einmal anzunehmen, wodurch potenzielle Engpässe bei hoher Last vermieden werden.

# /etc/nginx/nginx.conf

worker_processes auto; # Normalerweise auf 'auto' oder die Anzahl der CPU-Kerne eingestellt

events {
    worker_connections 1024; # Anpassung basierend auf Serverkapazität und erwarteter Last
    multi_accept on;
}

Tipp: Überwachen Sie die CPU-Auslastung Ihres Servers. Wenn worker_processes auf auto eingestellt ist und Ihre CPU-Auslastung konstant hoch ist, sollten Sie erwägen, worker_connections zu erhöhen oder Ihre Serverressourcen zu skalieren.

2. Effizientes Verbindungsmanagement

Die Optimierung der Art und Weise, wie Nginx Netzwerkverbindungen verwaltet, kann den Overhead reduzieren und die Reaktionsfähigkeit verbessern.

keepalive_timeout

Gibt an, wie lange eine Keep-Alive-Clientverbindung geöffnet bleibt. Die Wiederverwendung von Verbindungen reduziert den Overhead beim Aufbau neuer TCP-Verbindungen und SSL-Handshakes. Ein üblicher Wert liegt je nach Interaktivität Ihrer Anwendung zwischen 15 und 65 Sekunden.

sendfile

Ermöglicht die direkte Übertragung von Daten zwischen Dateideskriptoren und umgeht dabei den Puffer im User-Space. Dies verbessert die Leistung beim Ausliefern statischer Dateien erheblich.

tcp_nopush

Arbeitet mit sendfile zusammen. Nginx versucht, den HTTP-Header und den Anfang der Datei in einem einzigen Paket zu senden. Danach werden Daten in vollständigen Paketen gesendet. Dies reduziert die Anzahl der gesendeten Pakete.

tcp_nodelay

Weist Nginx an, Daten sofort nach Verfügbarkeit zu senden, ohne zu puffern. Dies ist vorteilhaft für interaktive Anwendungen, bei denen geringe Latenz wichtiger ist als die Maximierung des Durchsatzes (z. B. Chat-Anwendungen oder Echtzeit-Updates).

http {
    keepalive_timeout 65; # Keep-Alive-Verbindungen für 65 Sekunden
    sendfile on;
    tcp_nopush on; # Erfordert sendfile on
    tcp_nodelay on; # Nützlich für das Proxieren dynamischer Inhalte
}

3. Pufferoptimierung

Nginx verwendet Puffer, um Client-Anfragen und Antworten von Upstream-Servern (wie Anwendungsservern) zu verarbeiten. Die richtige Dimensionierung dieser Puffer kann unnötige Festplatten-I/O verhindern, den Speicherverbrauch reduzieren und den Durchsatz verbessern.

Client-Puffer

• client_body_buffer_size: Größe des Puffers für Client-Anforderungskörper. Wenn ein Körper diesen überschreitet, wird er in eine temporäre Datei geschrieben.
• client_header_buffer_size: Größe des Puffers für die erste Zeile und die Header einer Client-Anfrage.
• large_client_header_buffers: Definiert die Anzahl und Größe größerer Puffer zum Lesen von Client-Anforderungsheadern. Nützlich für Anfragen mit vielen Cookies oder langen Referer-Headern.

Proxy-Puffer (für Reverse-Proxy-Setups)

• proxy_buffers: Die Anzahl und Größe der Puffer, die zum Lesen von Antworten vom proxyserver verwendet werden.
• proxy_buffer_size: Die Größe des ersten Puffers zum Lesen der Antwort. Typischerweise kleiner, da er oft nur Header enthält.
• proxy_busy_buffers_size: Der maximale Umfang von Antwortpuffern, die zu einem bestimmten Zeitpunkt im Zustand „beschäftigt“ (aktiv an den Client gesendet) sein dürfen.

FastCGI-Puffer (für PHP-FPM, etc.)

• fastcgi_buffers: Die Anzahl und Größe der Puffer, die zum Lesen von Antworten vom FastCGI-Server verwendet werden.
• fastcgi_buffer_size: Die Größe des ersten Puffers zum Lesen der Antwort.

http {
    # Client-Puffer
    client_body_buffer_size 1M; # Anpassung basierend auf der erwarteten Anforderungskörpergröße (z. B. Datei-Uploads)
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k; # 4 Puffer, jeder 8KB groß

    # Proxy-Puffer (wenn Nginx als Reverse-Proxy fungiert)
    proxy_buffers 8 16k; # 8 Puffer, jeder 16KB
    proxy_buffer_size 16k; # Erster Puffer 16KB
    proxy_busy_buffers_size 16k; # Max. 16KB an beschäftigten Puffern

    # FastCGI-Puffer (wenn Nginx mit PHP-FPM arbeitet)
    fastcgi_buffers 116 8k; # 116 Puffer, jeder 8KB (z. B. für WordPress)
    fastcgi_buffer_size 16k; # Erster Puffer 16KB
}

Warnung: Zu klein eingestellte Puffer können zu Festplatten-I/O und Leistungsverschlechterung führen. Zu groß eingestellte Puffer können übermäßigen Speicher verbrauchen. Finden Sie durch Tests eine Balance.

4. Implementierung robuster Caching-Strategien

Caching ist eine der effektivsten Möglichkeiten, die Leistung zu verbessern und die Last auf Ihren Backend-Servern zu reduzieren. Nginx kann als leistungsstarker Content-Cache fungieren.

proxy_cache_path

Definiert den Pfad zum Cache-Verzeichnis, seine Größe, die Anzahl der Unterverzeichnisebenen und wie lange inaktive Elemente im Cache verbleiben.

proxy_cache

Aktiviert das Caching für einen bestimmten location-Block und verweist auf die in proxy_cache_path definierte Zone.

proxy_cache_valid

Legt die Zeit fest, für die Nginx Antworten mit bestimmten HTTP-Statuscodes zwischenspeichern soll.

proxy_cache_revalidate

Wenn aktiviert, verwendet Nginx If-Modified-Since- und If-None-Match-Header, um zwischengespeicherte Inhalte mit dem Backend neu zu validieren, wodurch der Bandbreitenverbrauch reduziert wird.

proxy_cache_use_stale

Weist Nginx an, veraltete zwischengespeicherte Inhalte auszuliefern, wenn der Backend-Server ausgefallen, nicht reagiert oder Fehler aufweist. Dies verbessert die Verfügbarkeit erheblich.

expires

Setzt Cache-Control- und Expires-Header für das clientseitige Caching statischer Dateien. Dies minimiert wiederholte Anfragen an Nginx.

http {
    # Definiere eine Proxy-Cache-Zone im http-Block
    proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=10g;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_upstream_backend;
            proxy_cache my_cache; # Caching für diesen Ort aktivieren
            proxy_cache_valid 200 302 10m; # Erfolgreiche Antworten 10 Minuten lang cachen
            proxy_cache_valid 404 1m; # 404er für 1 Minute cachen
            proxy_cache_revalidate on;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X-Cache-Status $upstream_cache_status; # Hilft beim Debuggen
        }

        # Statische Dateien für längere Zeit im Browser cachen
        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            expires 30d; # 30 Tage lang cachen
            add_header Cache-Control "public, no-transform";
            # Bei statischen Dateien erwägen, sie direkt von Nginx auszuliefern, wenn nicht proxied
            root /var/www/html;
        }
    }
}

5. Aktivieren der Gzip-Komprimierung

Das Komprimieren von Antworten vor dem Senden an Clients kann die Bandbreitennutzung erheblich reduzieren und die Ladezeiten von Seiten verbessern, insbesondere bei textbasierten Inhalten.

gzip on

Aktiviert die Gzip-Komprimierung.

gzip_comp_level

Legt die Komprimierungsstufe fest (1-9). Stufe 1 ist am schnellsten bei weniger Komprimierung; Stufe 9 ist am langsamsten bei maximaler Komprimierung. Stufe 6 bietet normalerweise eine gute Balance.

gzip_types

Gibt die MIME-Typen an, die komprimiert werden sollen. Fügen Sie gängige Text-, CSS-, JavaScript- und JSON-Typen hinzu.

gzip_min_length

Legt die Mindestlänge einer Antwort (in Bytes) fest, für die die Komprimierung aktiviert werden soll. Kleine Dateien profitieren nicht viel und können aufgrund des Komprimierungs-Overheads sogar langsamer sein.

gzip_proxied

Weist Nginx an, Antworten auch dann zu komprimieren, wenn sie weitergeleitet werden. any ist ein gängiger Wert.

gzip_vary

Fügt den Header Vary: Accept-Encoding zu Antworten hinzu, wodurch Proxys darüber informiert werden, dass die Antwort je nach Accept-Encoding-Anforderungsheader variieren kann.

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6; # Komprimierungsstufe 1-9 (6 ist eine gute Balance)
    gzip_buffers 16 8k; # 16 Puffer, jeder 8KB
    gzip_http_version 1.1; # Mindest-HTTP-Version für Komprimierung
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
    gzip_min_length 1000; # Nur Antworten komprimieren, die größer als 1KB sind
}

6. Protokollierung optimieren

Obwohl Protokolle für die Überwachung und Fehlerbehebung unerlässlich sind, kann eine übermäßige oder nicht optimierte Protokollierung erhebliche Festplatten-I/O verursachen, insbesondere bei Websites mit hohem Traffic.

access_log

• Für statische Assets deaktivieren: Bei häufig aufgerufenen statischen Inhalten (Bilder, CSS, JS) kann das Deaktivieren von access_log viel I/O einsparen.
• Pufferung: Nginx kann Protokolleinträge im Speicher puffern, bevor sie auf die Festplatte geschrieben werden, wodurch die Häufigkeit von Schreibvorgängen reduziert wird. Hierfür werden die Parameter buffer und flush verwendet.

error_log

Stellen Sie den entsprechenden Protokollierungsgrad ein (crit, error, warn, info, debug). Für die Produktion sind warn oder error in der Regel ausreichend, um kritische Probleme zu erfassen, ohne die Protokolle zu überfluten.

http {
    server {
        # Standard-Zugriffsprotokoll für dynamische Inhalte
        access_log /var/log/nginx/access.log main;

        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            access_log off; # Protokollierung für gängige statische Dateien deaktivieren
            expires 30d;
        }
    }

    # Beispiel für ein gepuffertes Zugriffsprotokoll für den Haupt-HTTP-Kontext
    # access_log /var/log/nginx/access.log main buffer=16k flush=5s;
    error_log /var/log/nginx/error.log warn; # Nur Warnungen und höhere Stufen protokollieren
}

7. Timeouts einstellen

Eine angemessen konfigurierte Timeout-Einstellung verhindert, dass Nginx inaktive Verbindungen zu lange offen hält, wodurch Ressourcen freigegeben werden.

Clientseitige Timeouts

• client_body_timeout: Wie lange Nginx wartet, bis ein Client den Anforderungskörper sendet.
• client_header_timeout: Wie lange Nginx wartet, bis ein Client den Anforderungsheader sendet.
• send_timeout: Wie lange Nginx wartet, bis ein Client die Antwort akzeptiert, nachdem sie gesendet wurde.

Proxy-/FastCGI-Timeouts (falls zutreffend)

• proxy_connect_timeout: Timeout für den Aufbau einer Verbindung mit einem proxyserver.
• proxy_send_timeout: Timeout für die Übertragung einer Anfrage an den proxyserver.
• proxy_read_timeout: Timeout für das Lesen einer Antwort vom proxyserver.

http {
    client_body_timeout 15s; # Client hat 15 Sekunden Zeit, den Körper zu senden
    client_header_timeout 15s; # Client hat 15 Sekunden Zeit, Header zu senden
    send_timeout 15s; # Nginx hat 15 Sekunden Zeit, die Antwort an den Client zu senden

    # Für Proxy-Szenarien
    proxy_connect_timeout 5s; # 5 Sekunden bis zur Verbindung mit dem Upstream
    proxy_send_timeout 15s; # 15 Sekunden zum Senden der Anfrage an den Upstream
    proxy_read_timeout 15s; # 15 Sekunden zum Lesen der Antwort vom Upstream

    # Für FastCGI-Szenarien
    fastcgi_connect_timeout 5s;
    fastcgi_send_timeout 15s;
    fastcgi_read_timeout 15s;
}

8. SSL/TLS-Optimierung

Bei HTTPS-aktivierten Websites ist die Optimierung der SSL/TLS-Einstellungen entscheidend, um den CPU-Overhead zu reduzieren und die Handshake-Leistung zu verbessern.

ssl_session_cache und ssl_session_timeout

SSL-Sitzungscaching aktivieren, um den rechenintensiven vollständigen TLS-Handshake für nachfolgende Verbindungen desselben Clients zu vermeiden.

ssl_protocols und ssl_ciphers

Verwenden Sie moderne, starke TLS-Protokolle (wie TLSv1.2 und TLSv1.3) und sichere Chiffriersuiten. Bevorzugen Sie Server-Chiffren mit ssl_prefer_server_ciphers on.

ssl_stapling

Aktiviert OCSP-Stapling, bei dem Nginx die OCSP-Antwort von der Zertifizierungsstelle (CA) regelmäßig abruft und sie an den SSL/TLS-Handshake „anheftet“. Dies reduziert die clientseitige Latenz, da eine separate OCSP-Abfrage vermieden wird.

server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;

    ssl_session_cache shared:SSL:10m; # Gemeinsamer Cache für 10MB an Sitzungsdaten
    ssl_session_timeout 10m; # Sitzungen laufen nach 10 Minuten ab

    ssl_protocols TLSv1.2 TLSv1.3; # Moderne, sichere Protokolle verwenden
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s; # DNS-Resolver für OCSP-Abfragen angeben
    resolver_timeout 5s;
}

9. Open File Cache

Nginx kann Dateideskriptoren für häufig aufgerufene Dateien im Cache speichern, wodurch die Notwendigkeit wiederholter Systemaufrufe zum Öffnen und Schließen von Dateien reduziert wird.

open_file_cache

Aktiviert den Cache und gibt die maximale Anzahl der Elemente und die Dauer an, für die inaktive Elemente aufbewahrt werden.

open_file_cache_valid

Legt fest, wie oft der Cache die Gültigkeit seiner Elemente überprüfen soll.

open_file_cache_min_uses

Gibt die Mindestanzahl der Zugriffe auf eine Datei innerhalb der inactive-Zeit an, damit sie im Cache verbleibt.

open_file_cache_errors

Bestimmt, ob Nginx Fehler beim Öffnen von Dateien im Cache speichern soll.

http {
    open_file_cache max=100000 inactive=60s; # Bis zu 100.000 Dateideskriptoren für 60s cachen
    open_file_cache_valid 80s; # Gültigkeit alle 80 Sekunden prüfen
    open_file_cache_min_uses 1; # Dateien cachen, auf die mindestens einmal zugegriffen wurde
    open_file_cache_errors on; # Fehler im Zusammenhang mit dem Öffnen von Dateien cachen
}

Fazit

Die Leistungsoptimierung von Nginx ist ein fortlaufender Prozess und keine einmalige Einrichtung. Diese Checkliste bietet einen robusten Ausgangspunkt für die Optimierung Ihrer Websites mit hohem Traffic. Denken Sie daran, dass die „perfekte“ Konfiguration stark von Ihrer spezifischen Anwendung, Ihren Verkehrsmustern und Ihren Serverressourcen abhängt. Testen Sie Änderungen immer zuerst in einer Staging-Umgebung, bevor Sie sie in der Produktion bereitstellen, und überwachen Sie kontinuierlich Ihre Nginx-Instanzen und Backend-Server mithilfe von Tools wie der Live-Aktivitätsüberwachung von Nginx Plus, Prometheus, Grafana oder grundlegenden Systemtools (z. B. top, iostat, netstat).

Durch die sorgfältige Anwendung dieser Optimierungen und deren Anpassung an Ihre Umgebung stellen Sie sicher, dass Nginx Inhalte auch unter den anspruchsvollsten Lasten mit außergewöhnlicher Geschwindigkeit, Effizienz und Zuverlässigkeit bereitstellt.