Průběh zpracování HTTP v Nginx: Ladění konfigurace

Výchozí konfigurace Nginx je navržena s ohledem na kompatibilitu, nikoli na výkon. Při správném ladění může jeden server zpracovat 50 000 až 80 000 požadavků za sekundu. Tato příručka se zabývá nejdůležitějšími nastaveními: pracovními procesy, připojeními, keepalive, ukládáním do vyrovnávací paměti, vyvažováním zátěže a tím, jak ověřit provedené změny pomocí benchmarků.

Jak Nginx zpracovává HTTP požadavky

Nginx zpracovává požadavky v jednotlivých fázích, z nichž každá spotřebovává systémové zdroje. Pochopení tohoto toku vám pomůže zvolit správná nastavení.

Začíná to na úrovni jádra. Příchozí připojení končí ve frontách SYN a ACCEPT a pracovní procesy Nginxu je převezmou. Jakmile je požadavek přijat, pracovní proces analyzuje HTTP požadavek z vyrovnávací paměti jádra. TLS provoz činí tento krok náročnějším na CPU.

Dále Nginx přiřadí požadavek k virtuálnímu serveru pomocí hlavičky Host a kombinace IP/portu, poté vyřeší URI do bloku umístění pomocí shody s předponou nebo regulárním výrazem.

U dynamického obsahu Nginx předá požadavek na backend (FastCGI, proxy). Tato fáze komunikace s upstreamem výrazně těží z trvalých připojení. Bez upstreamového keepalive Nginx otevírá nové TCP připojení pro každý požadavek, což zvyšuje latenci a zatížení procesoru.

Je-li proxy_buffering je povoleno, Nginx načte celou upstreamovou odpověď do paměti, než ji doručí klientovi. To uvolní pracovní proces, aby mohl okamžitě zpracovávat nové požadavky. Nakonec, během doručování výstupu, povolení sendfile umožňuje přenosy bez kopírování, což může zvýšit propustnost z přibližně 6 Gbps na 30 Gbps.

Každá fáze spotřebovává paměťové buffery, deskriptory souborů a cykly CPU. Následující části se zaměřují na jednotlivá úzká místa.

Pracovní procesy a připojení

Začněte s worker_processes auto; ve vašem hlavním kontextu. Tím se počet pracovníků přizpůsobí počtu jader vašeho procesoru. Na VPS s omezeným počtem jader nastavte počet ručně (např. worker_processes 2;). Pokud je vaše pracovní zátěž náročná na paměť, zvažte snížení počtu pracovníků, abyste se vyhnuli nadměrnému zatížení RAM.

Povolte worker_cpu_affinity auto; , aby byl každý pracovník přiřazen ke konkrétnímu jádru. Tím se sníží počet chyb cache a přepínání kontextu. K dispozici od Nginx 1.9.10.

Limity připojení

Direktiva worker_connections určuje, kolik souběžných připojení může každý pracovník zpracovat. Celková kapacita je worker_processes × worker_connections. Výchozí hodnota 512 nebo 1 024 je pro produkční prostředí příliš nízká. Pro weby s vysokým provozem ji nastavte na 2 048 nebo 4 096 na jeden pracovní proces.

Každé připojení potřebuje alespoň jeden popisovač souboru. V konfiguraci reverzního proxy používá každé připojení dva (jeden pro klienta, jeden pro upstream). Nastavte worker_rlimit_nofile hodnotu alespoň na dvojnásobek worker_connections hodnotu s rezervou. Pro worker_connections 4096;použijte worker_rlimit_nofile 10000; nebo vyšší.

Na systémové úrovni zvyšte fs.file-max na /etc/sysctl.conf alespoň na 500 000 a nastavte LimitNOFILE=65535.

Nakonec přidejte multi_accept on; do bloku events, aby pracovníci přijímali všechna čekající připojení najednou, nikoli po jednom.

Časové limity a Keepalive

Keepalive klienta

Směrnice keepalive_timeout řídí, jak dlouho zůstanou otevřená neaktivní klientská připojení. U serverů s vysokým provozem se osvědčuje 30 až 65 sekund. Použijte formu se dvěma parametry:

keepalive_timeout 65s 60s;

První hodnota je časový limit na straně serveru. Druhá hodnota odesílá Keep-Alive: timeout=60 hlavičku klientovi. Nastavení hodnoty na straně klienta o něco nižší zabrání závodním podmínkám, kdy se prohlížeče pokoušejí znovu použít připojení, která Nginx již uzavřel.

Směrnice keepalive_requests Omezuje počet požadavků, které jedno připojení zpracuje, než bude ukončeno. Výchozí hodnota je 1 000 (zvýšeno ze 100 ve verzi 1.19.10). U stabilních backendů tuto hodnotu zvyšte na 10 000, abyste snížili fluktuaci připojení.

Časové limity proxy

proxy_connect_timeout nastavuje, jak dlouho Nginx čeká na navázání spojení s backendem. Výchozí hodnota je 60 sekund. Pro rychlé převzetí služeb při selhání ji snižte na 5 až 10 sekund.

proxy_read_timeout určuje, jak dlouho Nginx čeká mezi po sobě jdoucími čteními z upstreamu. Sladěte tuto hodnotu s časovým limitem provedení vašeho backendu. Pokud je časový limit PHP-FPM request_terminate_timeout je 120 sekund, nastavte proxy_read_timeout na alespoň 120 sekund, abyste se vyhnuli předčasným chybám 504.

proxy_send_timeout řídí interval mezi po sobě jdoucími zápisy do upstreamu. Výchozí hodnota 60 sekund je obvykle dostačující, pokud neodesíláte velké těla požadavků.

Zpravidla by proxy_connect_timeout by měl být vždy nejkratší ze všech tří.

Velikost vyrovnávací paměti

client_body_buffer_size určuje, jak velkou část těla příchozího požadavku Nginx uchovává v paměti. Výchozí hodnota 8 kB nebo 16 kB zvládá jednoduché odesílání formulářů, ale nahrávání souborů se přesune na disk. Pro malé až střední nahrávky ji zvyšte na 128 kB. Zvyšte client_max_body_size z výchozí hodnoty 1 MB, pokud uživatelé nahrávají větší soubory.

proxy_buffer_size zpracovává hlavičky odpovědi odděleně od těla. Výchozí hodnota 4 kB nebo 8 kB obvykle funguje, ale aplikace s velkými Set-Cookie hlavičkami (běžné v e-commerce) ji mohou překročit, což způsobí chyby 502. Změřte si skutečnou velikost hlavičky:

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

Zaokrouhlete nahoru na nejbližší násobek 4 kB.

proxy_buffers nastavuje počet a velikost vyrovnávacích pamětí pro tělo odpovědi. Výchozí nastavení (8 vyrovnávacích pamětí o velikosti 4 kB nebo 8 kB, celkem 32 kB až 64 kB) nepojme velkou odpověď ve formátu JSON. Změřte svou největší typickou odpověď pomocí curl a nakonfigurujte dostatek vyrovnávacích pamětí, aby se vešla celá do RAM.

Chování vyrovnávací paměti proxy

S proxy_buffering on (výchozí nastavení) načte Nginx celou odpověď upstreamu do paměti před jejím odesláním klientovi. To umožňuje backendovým serverům okamžitě přejít k novým požadavkům.

Nastavte proxy_busy_buffers_size na hodnotu alespoň proxy_buffer_size plus jeden buffer, ale méně než celková velikost buffer poolu. Pro proxy_buffers 8 16k (celkem 128 kB) udržujte proxy_busy_buffers_size pod 112 kB.

U koncových bodů v reálném čase, jako jsou události odesílané serverem (Server-Sent Events) nebo dlouhé dotazování (long-polling), deaktivujte ukládání do vyrovnávací paměti pomocí proxy_buffering off v bloku specifickém pro dané umístění. Použijte to selektivně na /stream nebo /events , nikoli globálně.

Vyrovnávání zátěže a upstream keepalive

Ve výchozím nastavení otevírá Nginx nové TCP připojení pro každý proxy požadavek. Každé navázání spojení přidává 10 až 100 ms latence, přičemž TLS přidává dalších 10 až 50 ms. Upstream keepalive udržuje skupinu trvalých připojení, aby tuto zátěž eliminoval.

Jsou vyžadována tři nastavení:

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

Hodnota keepalive hodnota nastavuje maximální počet neaktivních připojení na jednoho pracovníka. Optimální velikost fondu vypočítáte takto: (workers × target concurrency) / upstream nodes.

Nastavte upstream keepalive_timeout na 60 až 120 sekund, aby odpovídalo nastavení vašeho backendu a zvládlo špičky v provozu.

Strategie vyvažování

Nginx podporuje několik metod vyvažování zátěže. Round-robin (výchozí) rozděluje požadavky postupně. least_conn směřuje na server s nejmenším počtem aktivních připojení, což vyhovuje pracovním zátěžím s proměnlivou délkou požadavků. ip_hash Zajišťuje perzistenci relace tím, že směruje stejnou IP adresu klienta na stejný backend.

Použijte parametr weight , pokud mají servery různou kapacitu:

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

Vážený server přijímá trojnásobek provozu. Server backup server se aktivuje pouze v případě, že jsou všechny primární servery mimo provoz. Nakonfigurujte max_fails a fail_timeout pro pasivní kontroly stavu a použijte max_conns k omezení počtu souběžných připojení na jeden backend.

Testování a monitorování

Vždy změřte základní výkon předtím, než něco změníte. Po každé změně proveďte znovu benchmark. Provádějte vždy pouze jednu změnu najednou.

Ověřte syntaxi konfigurace pomocí nginx -t před opětovným načtením. Spusťte testy výkonu ze samostatného počítače, abyste se vyhnuli soupeření o zdroje.

wrk je standardní nástroj pro zátěžové testování HTTP:

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

Sledujte počet požadavků za sekundu, průměrnou latenci, maximální latenci a přenosovou rychlost. Apache Bench je vhodný pro jednodušší testy:

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

Průběžné monitorování

Povolte modul stub_status modul pro monitorování aktivních připojení v reálném čase pomocí curl http://localhost/nginx_status.

Přidejte do formátu protokolu proměnné času, abyste zjistili, kde dochází ke zpožděním:

• $request_time pro celkovou dobu trvání požadavku
• $upstream_connect_time pro dobu připojení k backendu
• $upstream_response_time pro celkovou dobu zpracování na backendu

Zkontrolujte protokoly chyb, zda neobsahují problémy s vyrovnávací pamětí pomocí journalctl -u nginx --no-pager | grep "temporary file". Pokud se odpovědi ukládají na disk, vaše proxy_buffers jsou příliš malé. Hledejte chyby „příliš mnoho otevřených souborů“, které naznačují worker_rlimit_nofile je třeba zvětšit.

Snižte I/O protokolů pomocí ukládání do vyrovnávací paměti:

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

Použijte ss -tn state established dst [backend_ip] během zátěžových testů k ověření, zda se připojení znovu používají a nehromadí se v TIME_WAIT.

Pro dedikované servery a VPS hosting optimalizované pro vysoce výkonné pracovní zátěže viz FDC servery.