Nginx HTTP feldolgozási folyamat: konfigurációs beállítások

Az Nginx alapértelmezett konfigurációja a kompatibilitásra, nem pedig a teljesítményre van tervezve. Megfelelő hangolással egyetlen szerver másodpercenként 50 000–80 000 kérést képes kezelni. Ez az útmutató a legfontosabb beállításokat tárgyalja: munkavégző folyamatok, kapcsolatok, keepalive, pufferelés, terheléselosztás, valamint a változtatások benchmarkokkal történő ellenőrzése.

Hogyan dolgozza fel az Nginx a HTTP-kérelmeket

Az Nginx a kéréseket különálló fázisokban kezeli, amelyek mindegyike rendszererőforrásokat igényel. A folyamat megértése segít a megfelelő beállítások kiválasztásában.

A folyamat a rendszermag szintjén kezdődik. A bejövő kapcsolatok a SYN és ACCEPT sorokba kerülnek, ahonnan az Nginx munkaprogramjai veszik át őket. Az elfogadás után a munkaprogram elemzi a rendszermag pufferből származó HTTP-kérelmet. A TLS-forgalom miatt ez a lépés nagyobb CPU-terheléssel jár.

Ezután az Nginx a Host fejléc és az IP/port kombináció segítségével illeszti a kérést egy virtuális szerverhez, majd előtag vagy reguláris kifejezés illesztésével feloldja az URI-t egy helyblokkba.

Dinamikus tartalom esetén az Nginx továbbítja a kérést egy háttérszolgáltatásnak (FastCGI, proxy). Ez az upstream kommunikációs fázis nagyban profitál a tartós kapcsolatokból. Upstream keepalive nélkül az Nginx minden kéréshez új TCP-kapcsolatot nyit, ami növeli a késleltetést és a CPU-terhelést.

Ha proxy_buffering be van kapcsolva, az Nginx a teljes upstream választ beolvassa a memóriába, mielőtt továbbítaná azt az ügyfélnek. Ez felszabadítja a munkavállalót, hogy azonnal kezelhesse az új kéréseket. Végül, a kimeneti szállítás során a sendfile lehetővé teszi a zero-copy átviteleket, ami az átviteli sebességet körülbelül 6 Gbps-ről 30 Gbps-re növelheti.

Minden fázis memóriabuffereket, fájl leírókat és CPU ciklusokat fogyaszt. Az alábbi szakaszok az egyes szűk keresztmetszeteket célozzák meg.

Munkavégző folyamatok és kapcsolatok

Kezdje a worker_processes auto; a fő kontextusban. Ez a munkavégzők számát a CPU magok számához igazítja. Korlátozott magszámú VPS esetén állítsa be a számot manuálisan (pl. worker_processes 2;). Ha a munkaterhelés memóriát igényel, fontolja meg a munkavállalók számának csökkentését, hogy elkerülje a RAM túlterhelését.

Engedélyezze worker_cpu_affinity auto; , hogy minden munkavállalót egy adott maghoz rendeljen. Ez csökkenti a cache-hibákat és a kontextusváltásokat. Az Nginx 1.9.10 verziótól elérhető.

Kapcsolati korlátozások

A worker_connections direktíva határozza meg, hogy egy-egy munkavégző hány egyidejű kapcsolatot tud kezelni. A teljes kapacitás worker_processes × worker_connections. Az alapértelmezett 512 vagy 1024 túl alacsony a termelési környezetben. Nagy forgalmú webhelyek esetén állítsa be 2048-ra vagy 4096-ra munkavállalónként.

Minden kapcsolatnak legalább egy fájl leírójára van szüksége. Fordított proxy beállítás esetén minden kapcsolat kettőt használ (egyet az ügyfélnek, egyet az upstreamnek). Állítsa be worker_rlimit_nofile értéket legalább a worker_connections értékét, és hagyjon tartalékot. worker_connections 4096;, használjon worker_rlimit_nofile 10000; vagy magasabb értéket.

Rendszer szinten növelje fs.file-max értékét /etc/sysctl.conf értéket legalább 500 000-re, és állítsa be a systemd LimitNOFILE=65535.

Végül adja hozzá multi_accept on; az events blokkba, hogy a munkások egyszerre fogadják el az összes függőben lévő kapcsolatot, ahelyett, hogy egyenként tennék.

Időkorlátok és Keepalive

Ügyfél keepalive

A keepalive_timeout utasítás szabályozza, hogy a tétlen klienskapcsolatok mennyi ideig maradjanak nyitva. Nagy forgalmú szerverek esetében a 30–65 másodperc jól működik. Használja a kétparaméteres formát:

keepalive_timeout 65s 60s;

Az első érték a szerver oldali időkorlát. A második egy Keep-Alive: timeout=60 fejléceket az ügyfélnek. Ha az ügyfél értékét kissé alacsonyabbra állítja, elkerülheti azokat a versengési helyzeteket, amikor a böngészők megpróbálják újra felhasználni azokat a kapcsolatokat, amelyeket az Nginx már bezárt.

A keepalive_requests utasítás korlátozza, hogy egy kapcsolat hány kérést kezelhet, mielőtt lezárul. Az alapértelmezett érték 1000 (a 1.19.10-es verzióban 100-ról emelték). Stabil háttérszolgáltatások esetén növelje ezt 10 000-re a kapcsolatváltások csökkentése érdekében.

A proxy időkorlátok

proxy_connect_timeout meghatározza, hogy az Nginx mennyi ideig vár a háttérrel való kapcsolat létrehozására. Az alapértelmezett érték 60 másodperc. Gyors átállás érdekében csökkentse 5–10 másodpercre.

proxy_read_timeout meghatározza, hogy az Nginx mennyi ideig vár az upstream-től érkező egymást követő olvasások között. Igazítsa a háttérrendszer végrehajtási időkorlátjához. Ha a PHP-FPM request_terminate_timeout 120 másodperc, állítsa be proxy_read_timeout legalább 120 másodpercre, hogy elkerülje a korai 504-es hibákat.

proxy_send_timeout szabályozza az upstream-hez történő egymást követő írások közötti időközöket. Az alapértelmezett 60 másodperc általában megfelelő, kivéve, ha nagy méretű kérés-testeket küld.

Általános szabály, hogy proxy_connect_timeout -nek mindig a három közül a legrövidebbnek kell lennie.

A puffer mérete

client_body_buffer_size szabályozza, hogy az Nginx a beérkező kérések testének mekkora részét tárolja a memóriában. Az alapértelmezett 8k vagy 16k érték egyszerű űrlapküldéseket kezel, de a fájlfeltöltések a lemezre kerülnek. Kis- és közepes méretű feltöltések esetén növelje 128k-ra. client_max_body_size az alapértelmezett 1 MB-os értéket, ha a felhasználók nagyobb fájlokat töltenek fel.

proxy_buffer_size A válaszfejléceket a testtől függetlenül kezeli. Az alapértelmezett 4k vagy 8k érték általában megfelelő, de a nagy Set-Cookie fejlécekkel rendelkező alkalmazások (gyakori az e-kereskedelemben) túlléphetik ezt a méretet, ami 502-es hibákat okozhat. Mérje meg a fejlécek tényleges méretét:

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

Kerekítsen fel a legközelebbi 4k-s lépésre.

proxy_buffers beállítja a válasz testéhez tartozó pufferek számát és méretét. Az alapértelmezett érték (8 db 4k-s vagy 8k-s puffer, összesen 32k–64k) nem képes befogadni egy nagy JSON-választ. Mérje meg a legnagyobb tipikus válaszát curl és állítson be elegendő puffert ahhoz, hogy az teljes egészében a RAM-ban maradjon.

Proxy pufferelési viselkedés

A proxy_buffering on (alapértelmezett) beállítással az Nginx a teljes upstream választ beolvassa a memóriába, mielőtt elküldené azt az ügyfélnek. Ez lehetővé teszi a háttérszerverek számára, hogy azonnal továbblépjenek az új kérésekre.

Állítsa proxy_busy_buffers_size legalább proxy_buffer_size plusz egy pufferre, de kevesebbre, mint a teljes pufferpool mérete. proxy_buffers 8 16k (összesen 128k), tartsa proxy_busy_buffers_size 112k alatt.

Valós idejű végpontok, például a Server-Sent Events vagy a hosszú lekérdezés (long-polling) esetén tiltsa le a pufferelést proxy_buffering off egy helyspecifikus blokkban. Ezt szelektíven alkalmazza /stream vagy /events útvonalakra, ne globálisan.

Terheléselosztás és upstream keepalive

Alapértelmezés szerint az Nginx minden proxy-kéréshez új TCP-kapcsolatot nyit. Minden kézfogás 10–100 ms késleltetést jelent, a TLS pedig további 10–50 ms-ot. Az upstream keepalive állandó kapcsolatokból álló poolt tart fenn, hogy kiküszöbölje ezt a többletterhelést.

Három beállítás szükséges:

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

A keepalive érték határozza meg a munkavállalónkénti maximális tétlen kapcsolatok számát. Az optimális pool méretét a következőképpen számítsa ki: (workers × target concurrency) / upstream nodes.

Állítsa be az upstream keepalive_timeout értéket 60–120 másodpercre, hogy megfeleljen a háttérrendszer beállításainak és kezelni tudja a forgalmi csúcsokat.

Terheléselosztási stratégiák

Az Nginx több terheléselosztási módszert is támogat. A Round-robin (alapértelmezett) a kéréseket egymás után osztja szét. least_conn a legkevesebb aktív kapcsolattal rendelkező szerverre irányítja a forgalmat, ami változó kérésidővel rendelkező terhelések esetén megfelelő. ip_hash biztosítja a munkamenet-perzisztenciát azáltal, hogy ugyanazt az ügyfél-IP-címet ugyanahhoz a háttérszerverhez irányítja.

Használja a weight paramétert, ha a szerverek kapacitása eltérő:

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

A súlyozott szerver a forgalom háromszorosát kapja. A backup szerver csak akkor aktiválódik, ha az összes elsődleges szerver leállt. Konfigurálja max_fails és fail_timeout a passzív állapotellenőrzésekhez, és használja a max_conns a háttérszolgáltatónkénti egyidejű kapcsolatok korlátozásához.

Tesztelés és monitorozás

Minden változtatás előtt mindig mérje meg az alapteljesítményt. Minden változtatás után végezzen újra teljesítménymérést. Egyszerre csak egy változtatást hajtson végre.

Ellenőrizze a konfigurációs szintaxist a nginx -t parancs segítségével. A teljesítménymérést külön gépről futtassa, hogy elkerülje az erőforrásokért folyó versengést.

A wrk a HTTP terheléses tesztelés standard eszköze:

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

Kövesse nyomon a másodpercenkénti kéréseket, az átlagos késleltetést, a maximális késleltetést és az átviteli sebességet. Az Apache Bench egyszerűbb tesztekhez használható:

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

Folyamatos figyelés

Engedélyezze a stub_status modult az aktív kapcsolatok valós idejű figyeléséhez a curl http://localhost/nginx_status.

Adjon hozzá időváltozókat a naplóformátumhoz, hogy azonosítani tudja, hol történnek késések:

• $request_time a teljes kérés időtartamához
• $upstream_connect_time a háttérkapcsolat idejéhez
• $upstream_response_time a teljes háttérfeldolgozási időhöz

Ellenőrizze a hibanaplókat a pufferproblémák felderítéséhez a journalctl -u nginx --no-pager | grep "temporary file". Ha a válaszok a lemezre kerülnek, akkor a proxy_buffers túl kicsi. Keresse meg a „túl sok nyitott fájl” hibákat, amelyek azt jelzik, hogy worker_rlimit_nofile növelésre szorul.

Csökkentse a napló I/O-ját pufferelt naplózással:

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

Használja ss -tn state established dst [backend_ip] terheléses tesztek során ellenőrizze, hogy a kapcsolatok újrahasznosításra kerülnek-e, és nem halmozódnak-e fel a TIME_WAIT állapotban.

A nagy teljesítményű munkaterhelésekre optimalizált dedikált szerverek és VPS-tárhelyekről az FDC szerverek oldalon olvashat.