Nginx HTTP-bearbetningsflöde: Konfigurationsjustering

Nginx standardkonfiguration är utformad för kompatibilitet, inte prestanda. Med rätt inställningar kan en enda server hantera 50 000 till 80 000 förfrågningar per sekund. Denna guide täcker de inställningar som är viktigast: arbetsprocesser, anslutningar, keepalive, buffring, lastbalansering och hur du verifierar dina ändringar med prestandatester.

Hur Nginx bearbetar HTTP-förfrågningar

Nginx hanterar förfrågningar i olika faser, som var och en förbrukar systemresurser. Att förstå flödet hjälper dig att välja rätt inställningar.

Det börjar på kärnnivå. Inkommande anslutningar hamnar i SYN- och ACCEPT-köer, och Nginx-arbetsprocesser hämtar dem. När de har accepterats analyserar arbetsprocessen HTTP-förfrågan från kärnbuffert. TLS-trafik gör detta steg mer CPU-krävande.

Därefter matchar Nginx förfrågan mot en virtuell server med hjälp av Host-rubriken och kombinationen av IP och port, och löser sedan URI till ett platsblock via prefix- eller regex-matchning.

För dynamiskt innehåll vidarebefordrar Nginx begäran till en backend (FastCGI, proxy). Denna uppströms kommunikationsfas drar stor nytta av beständiga anslutningar. Utan uppströms keepalive öppnar Nginx en ny TCP-anslutning per begäran, vilket ökar latensen och CPU-belastningen.

Om proxy_buffering är aktiverat läser Nginx in hela uppströms-svaret i minnet innan det levereras till klienten. Detta frigör arbetaren så att den omedelbart kan hantera nya förfrågningar. Slutligen, under utmatningsleveransen, möjliggör sendfile möjliggörs överföringar utan kopiering, vilket kan öka genomströmningen från cirka 6 Gbps till 30 Gbps.

Varje fas förbrukar minnesbuffertar, filbeskrivare och CPU-cykler. Avsnitten nedan riktar in sig på varje flaskhals.

Arbetsprocesser och anslutningar

Börja med worker_processes auto; i ditt huvudkontext. Detta anpassar antalet arbetare till dina CPU-kärnor. På en VPS med begränsat antal kärnor ställer du in antalet manuellt (t.ex. worker_processes 2;). Om din arbetsbelastning är minneskrävande bör du överväga att minska antalet arbetare för att undvika att överbelasta RAM-minnet.

Aktivera worker_cpu_affinity auto; för att koppla varje arbetare till en specifik kärna. Detta minskar cache-missar och kontextväxlingar. Tillgängligt sedan Nginx 1.9.10.

Anslutningsbegränsningar

Direktivet worker_connections -direktivet anger hur många samtidiga anslutningar varje worker kan hantera. Total kapacitet är worker_processes × worker_connections. Standardvärdet 512 eller 1 024 är för lågt för produktion. Ställ in det på 2 048 eller 4 096 per arbetare för webbplatser med hög trafik.

Varje anslutning behöver minst en filbeskrivare. I en omvänd proxy-konfiguration använder varje anslutning två (en för klienten, en för uppströms). Ställ in worker_rlimit_nofile till minst dubbelt så mycket som ditt worker_connections värde med marginal. För worker_connections 4096;, använd worker_rlimit_nofile 10000; eller högre.

På systemnivå, öka fs.file-max till /etc/sysctl.conf till minst 500 000 och ställ in systemds LimitNOFILE=65535.

Slutligen, lägg till multi_accept on; i händelseblocket så att arbetare accepterar alla väntande anslutningar på en gång istället för en i taget.

Timeouts och Keepalive

Klient-keepalive

Direktivet keepalive_timeout styr hur länge inaktiva klientanslutningar förblir öppna. För servrar med hög trafik fungerar 30 till 65 sekunder bra. Använd formen med två parametrar:

keepalive_timeout 65s 60s;

Det första värdet är tidsgränsen på serversidan. Det andra skickar en Keep-Alive: timeout=60 header till klienten. Att ställa in klientvärdet något lägre förhindrar race-förhållanden där webbläsare försöker återanvända anslutningar som Nginx redan har stängt.

Direktivet keepalive_requests begränsar hur många förfrågningar en enskild anslutning hanterar innan den stängs. Standardvärdet är 1 000 (höjt från 100 i version 1.19.10). För stabila backends bör du öka detta till 10 000 för att minska anslutningsomsättningen.

Proxy-timeouts

proxy_connect_timeout ställer in hur länge Nginx väntar på att upprätta en anslutning med backend. Standardvärdet är 60 sekunder. Minska det till 5 till 10 sekunder för snabb failover.

proxy_read_timeout definierar hur länge Nginx väntar mellan på varandra följande läsningar från uppströms. Anpassa det efter din backends exekveringstimeout. Om PHP-FPM:s request_terminate_timeout är 120 sekunder, ställ in proxy_read_timeout till minst 120 sekunder för att undvika för tidiga 504-fel.

proxy_send_timeout styr intervallet mellan på varandra följande skrivningar till uppströms. Standardvärdet på 60 sekunder brukar fungera bra såvida du inte skickar stora förfrågningskroppar.

Som regel proxy_connect_timeout bör alltid vara den kortaste av de tre.

Buffertstorlek

client_body_buffer_size styr hur mycket av en inkommande förfrågans innehåll som Nginx lagrar i minnet. Standardvärdet på 8k eller 16k hanterar enkla formulärinlämningar, men filuppladdningar kommer att spillas över till disken. Öka det till 128k för små till medelstora uppladdningar. Höj client_max_body_size från standardvärdet 1 MB om användarna laddar upp större filer.

proxy_buffer_size hanterar svarsrubriker separat från huvudtexten. Standardvärdet på 4k eller 8k fungerar vanligtvis, men applikationer med stora Set-Cookie rubriker (vanligt inom e-handel) kan överskrida detta, vilket orsakar 502-fel. Mät din faktiska rubrikstorlek:

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

Avrunda uppåt till närmaste 4k-steg.

proxy_buffers ställer in antalet och storleken på buffertar för svarskroppen. Standardinställningen (8 buffertar på 4k eller 8k, totalt 32k till 64k) rymmer inte ett stort JSON-svar. Mät ditt största typiska svar med curl och konfigurera tillräckligt med buffertar för att hålla det helt i RAM-minnet.

Proxybuffringens beteende

Med proxy_buffering on (standard) läser Nginx in hela uppströms-svaret i minnet innan det skickas till klienten. Detta gör att backend-servrarna omedelbart kan gå vidare till nya förfrågningar.

Ställ in proxy_busy_buffers_size till minst proxy_buffer_size plus en buffert, men mindre än din totala buffertpool. För proxy_buffers 8 16k (totalt 128 kB), håll proxy_busy_buffers_size under 112k.

För realtidsändpunkter som Server-Sent Events eller long-polling, inaktivera buffring med proxy_buffering off i ett platsspecifikt block. Tillämpa detta selektivt på /stream eller /events sökvägar, inte globalt.

Lastbalansering och Upstream Keepalive

Som standard öppnar Nginx en ny TCP-anslutning för varje proxyerad begäran. Varje handskakning tillför 10 till 100 ms fördröjning, och TLS tillför ytterligare 10 till 50 ms. Upstream keepalive upprätthåller en pool av beständiga anslutningar för att eliminera denna overhead.

Tre inställningar krävs:

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 "";
    }
}

Värdet keepalive värdet anger det maximala antalet inaktiva anslutningar per arbetare. Beräkna den optimala poolstorleken enligt följande: (workers × target concurrency) / upstream nodes.

Ställ in uppströms keepalive_timeout till 60 till 120 sekunder för att matcha inställningarna för din backend och hantera trafiktoppar.

Balanseringsstrategier

Nginx stöder flera metoder för lastbalansering. Round-robin (standard) fördelar förfrågningar sekventiellt. least_conn dirigerar till servern med minst antal aktiva anslutningar, vilket passar arbetsbelastningar med varierande förfrågningslängder. ip_hash ger sessionsbeständighet genom att dirigera samma klient-IP till samma backend.

Använd weight parametern när servrarna har olika kapacitet:

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;
}

Den viktade servern tar emot tre gånger så mycket trafik. backup servern aktiveras endast om alla primära servrar är nere. Konfigurera max_fails och fail_timeout för passiva hälsokontroller och använd max_conns för att begränsa antalet samtidiga anslutningar per backend.

Testning och övervakning

Mät alltid basprestandan innan du ändrar något. Efter varje ändring ska du göra ett nytt jämförelsetest. Gör en ändring i taget.

Validera din konfigurationssyntax med nginx -t innan du laddar om. Kör prestandatester från en separat maskin för att undvika resurskonflikter.

wrk är standardverktyget för HTTP-belastningstestning:

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

Spåra förfrågningar per sekund, genomsnittlig latens, maximal latens och överföringshastighet. Apache Bench fungerar för enklare tester:

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

Löpande övervakning

Aktivera stub_status modulen för att övervaka aktiva anslutningar i realtid via curl http://localhost/nginx_status.

Lägg till tidsvariabler i ditt loggformat för att identifiera var fördröjningar uppstår:

• $request_time för total begärandevaraktighet
• $upstream_connect_time för anslutningstid till backend
• $upstream_response_time för total backend-bearbetningstid

Kontrollera felloggarna för buffertproblem med journalctl -u nginx --no-pager | grep "temporary file". Om svaren hamnar på disken är din proxy_buffers för liten. Leta efter felmeddelanden om "för många öppna filer", vilket indikerar worker_rlimit_nofile behöver höjas.

Minska logg-I/O med buffrad loggning:

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

Använd ss -tn state established dst [backend_ip] under belastningstester för att verifiera att anslutningar återanvänds och inte staplas upp i TIME_WAIT.

För dedikerade servrar och VPS-hosting optimerade för högpresterande arbetsbelastningar, se FDC-servrar.