Fluxul de procesare HTTP Nginx: Reglarea configurației

Configurația implicită a Nginx este concepută pentru compatibilitate, nu pentru performanță. Cu o optimizare adecvată, un singur server poate gestiona între 50.000 și 80.000 de solicitări pe secundă. Acest ghid acoperă setările cele mai importante: procesele de lucru, conexiunile, keepalive, buffering, echilibrarea încărcării și modul de verificare a modificărilor cu ajutorul testelor de performanță.

Cum procesează Nginx cererile HTTP

Nginx gestionează cererile în faze distincte, fiecare consumând resurse de sistem. Înțelegerea fluxului vă ajută să vizați setările potrivite.

Procesul începe la nivel de kernel. Conexiunile primite ajung în cozile SYN și ACCEPT, iar procesele de lucru Nginx le preiau. Odată acceptate, procesul de lucru analizează solicitarea HTTP din bufferul kernelului. Traficul TLS face ca acest pas să solicite mai mult procesorul.

Apoi, Nginx potrivește solicitarea cu un server virtual folosind antetul Host și combinația IP/port, apoi rezolvă URI-ul într-un bloc de locații prin potrivire de prefix sau expresie regulată.

Pentru conținutul dinamic, Nginx redirecționează cererea către un backend (FastCGI, proxy). Această fază de comunicare în amonte beneficiază în mare măsură de conexiuni persistente. Fără keepalive în amonte, Nginx deschide o nouă conexiune TCP pentru fiecare cerere, adăugând latență și suprasolicitare a procesorului.

Dacă proxy_buffering este activat, Nginx citește răspunsul complet din amonte în memorie înainte de a-l livra clientului. Acest lucru eliberează procesorul de lucru pentru a gestiona imediat cereri noi. În cele din urmă, în timpul livrării de ieșire, activarea sendfile permite transferuri zero-copy, ceea ce poate crește debitul de la aproximativ 6 Gbps la 30 Gbps.

Fiecare fază consumă tampoane de memorie, descriptori de fișiere și cicluri CPU. Secțiunile de mai jos vizează fiecare blocaj.

Procese de lucru și conexiuni

Începeți cu worker_processes auto; în contextul principal. Aceasta potrivește numărul de procese de lucru cu nucleele procesorului. Pe un VPS cu nuclee limitate, setați numărul manual (de ex. worker_processes 2;). Dacă sarcina dvs. de lucru consumă multă memorie, luați în considerare reducerea numărului de procesori de lucru pentru a evita suprasolicitarea RAM-ului.

Activați worker_cpu_affinity auto; pentru a aloca fiecare proces de lucru unui nucleu specific. Aceasta reduce ratările de cache și comutarea de context. Disponibil începând cu Nginx 1.9.10.

Limite de conexiune

Directiva worker_connections stabilește câte conexiuni simultane poate gestiona fiecare worker. Capacitatea totală este worker_processes × worker_connections. Valoarea implicită de 512 sau 1.024 este prea mică pentru producție. Setați-o la 2.048 sau 4.096 per worker pentru site-urile cu trafic intens.

Fiecare conexiune are nevoie de cel puțin un descriptor de fișier. Într-o configurare de proxy invers, fiecare conexiune utilizează două (unul pentru client, unul pentru upstream). Setați worker_rlimit_nofile la cel puțin dublul worker_connections cu o marjă de siguranță. Pentru worker_connections 4096;, utilizați worker_rlimit_nofile 10000; sau o valoare mai mare.

La nivel de sistem, măriți fs.file-max în /etc/sysctl.conf la cel puțin 500.000 și setați LimitNOFILE=65535.

În cele din urmă, adăugați multi_accept on; în blocul de evenimente, astfel încât workerii să accepte toate conexiunile în așteptare simultan, în loc de câte una pe rând.

Timeout-uri și Keepalive

Keepalive client

Directiva keepalive_timeout directivă controlează cât timp rămân deschise conexiunile inactiv ale clienților. Pentru serverele cu trafic intens, o durată de 30 până la 65 de secunde funcționează bine. Utilizați forma cu doi parametri:

keepalive_timeout 65s 60s;

Prima valoare este timpul de expirare pe partea serverului. A doua trimite un Keep-Alive: timeout=60 antet către client. Setarea valorii clientului la un nivel ușor mai mic previne condițiile de concurență în care browserele încearcă să reutilizeze conexiunile pe care Nginx le-a închis deja.

Directiva keepalive_requests limitează numărul de cereri pe care o singură conexiune le poate gestiona înainte de a fi închisă. Valoarea implicită este 1.000 (mărită de la 100 în versiunea 1.19.10). Pentru backend-uri stabile, măriți această valoare la 10.000 pentru a reduce fluctuația conexiunilor.

Timpii de expirare ai proxy-ului

proxy_connect_timeout stabilește cât timp așteaptă Nginx pentru a stabili o conexiune cu backend-ul. Valoarea implicită este de 60 de secunde. Reduceți-o la 5-10 secunde pentru o preluare rapidă a eșecurilor.

proxy_read_timeout definește cât timp așteaptă Nginx între citirile succesive de la upstream. Aliniați-l cu timpul de expirare al execuției backend-ului dvs. Dacă cel al PHP-FPM request_terminate_timeout este de 120 de secunde, setați proxy_read_timeout la cel puțin 120 de secunde pentru a evita erorile 504 premature.

proxy_send_timeout controlează intervalul dintre scrierile succesive către upstream. Valoarea implicită de 60 de secunde este de obicei suficientă, cu excepția cazului în care trimiteți corpuri de cereri mari.

Ca regulă generală, proxy_connect_timeout ar trebui să fie întotdeauna cel mai scurt dintre cele trei.

Dimensiunea bufferului

client_body_buffer_size controlează cât din corpul unei cereri primite păstrează Nginx în memorie. Valoarea implicită de 8k sau 16k gestionează trimiterile simple de formulare, dar încărcările de fișiere se vor revărsa pe disc. Măriți-o la 128k pentru încărcări mici și medii. Măriți client_max_body_size valoarea implicită de 1m dacă utilizatorii încarcă fișiere mai mari.

proxy_buffer_size gestionează anteturile de răspuns separat de corp. Valoarea implicită de 4k sau 8k funcționează de obicei, dar aplicațiile cu antete mari Set-Cookie (frecvente în comerțul electronic) o pot depăși, provocând erori 502. Măsurați dimensiunea reală a antetului:

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

Rotunjiți la cea mai apropiată valoare de 4k.

proxy_buffers stabilește numărul și dimensiunea bufferelor pentru corpul răspunsului. Valoarea implicită (8 buffere de 4k sau 8k, totalizând 32k până la 64k) nu va putea stoca un răspuns JSON mare. Măsurați cel mai mare răspuns tipic cu curl și configurați suficienți bufferi pentru a-l păstra în întregime în RAM.

Comportamentul bufferului proxy

Cu proxy_buffering on (implicit), Nginx citește răspunsul complet din amonte în memorie înainte de a-l trimite clientului. Acest lucru permite serverelor backend să treacă imediat la noi cereri.

Setați proxy_busy_buffers_size la cel puțin proxy_buffer_size plus un buffer, dar mai puțin decât totalul buffer pool-ului. Pentru proxy_buffers 8 16k (128k în total), păstrați proxy_busy_buffers_size sub 112k.

Pentru punctele finale în timp real, cum ar fi Server-Sent Events sau long-polling, dezactivați stocarea în buffer cu proxy_buffering off într-un bloc specific locației. Aplicați acest lucru selectiv la /stream sau /events căi, nu la nivel global.

Echilibrarea încărcării și menținerea conexiunii upstream

În mod implicit, Nginx deschide o nouă conexiune TCP pentru fiecare cerere proxy. Fiecare handshake adaugă o latență de 10 până la 100 ms, iar TLS adaugă încă 10 până la 50 ms. Upstream keepalive menține un grup de conexiuni persistente pentru a elimina această suprasolicitare.

Sunt necesare trei setări:

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

Valoarea keepalive valoare stabilește numărul maxim de conexiuni inactive per worker. Calculați dimensiunea optimă a grupului după cum urmează: (workers × target concurrency) / upstream nodes.

Setați upstream keepalive_timeout la 60 până la 120 de secunde pentru a se potrivi cu setările backend-ului dvs. și pentru a gestiona vârfurile de trafic.

Strategii de echilibrare

Nginx acceptă mai multe metode de echilibrare a încărcării. Round-robin (implicit) distribuie cererile secvențial. least_conn redirecționează către serverul cu cele mai puține conexiuni active, ceea ce se potrivește sarcinilor de lucru cu durate variabile ale cererilor. ip_hash asigură persistența sesiunii prin redirecționarea aceleiași adrese IP a clientului către același backend.

Utilizați parametrul weight atunci când serverele au capacități diferite:

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

Serverul ponderat primește de trei ori mai mult trafic. backup server se activează numai dacă toate serverele primare sunt inactivate. Configurați max_fails și fail_timeout pentru verificări pasive de stare și utilizați max_conns pentru a limita conexiunile simultane pe backend.

Testare și monitorizare

Măsurați întotdeauna performanța de bază înainte de a modifica ceva. După fiecare modificare, efectuați din nou un test de performanță. Efectuați o singură modificare la un moment dat.

Validați sintaxa configurației cu nginx -t înainte de reîncărcare. Rulați testele de performanță de pe un computer separat pentru a evita conflictele de resurse.

wrk este instrumentul standard pentru testarea încărcării HTTP:

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

Urmăriți cererile pe secundă, latența medie, latența maximă și rata de transfer. Apache Bench funcționează pentru teste mai simple:

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

Monitorizare continuă

Activați modulul stub_status modulul pentru a monitoriza conexiunile active în timp real prin curl http://localhost/nginx_status.

Adăugați variabile de timp la formatul jurnalului pentru a identifica unde apar întârzierile:

• $request_time pentru durata totală a cererii
• $upstream_connect_time pentru timpul de conectare la backend
• $upstream_response_time pentru timpul total de procesare backend

Verificați jurnalele de erori pentru probleme de buffer cu journalctl -u nginx --no-pager | grep "temporary file". Dacă răspunsurile ajung pe disc, proxy_buffers sunt prea mici. Căutați erori de tipul „prea multe fișiere deschise”, care indică worker_rlimit_nofile trebuie mărite.

Reduceți I/O-ul jurnalului cu jurnalizarea în buffer:

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

Utilizați ss -tn state established dst [backend_ip] în timpul testelor de încărcare pentru a verifica dacă conexiunile sunt reutilizate și nu se acumulează în TIME_WAIT.

Pentru servere dedicate și găzduire VPS optimizate pentru sarcini de lucru de înaltă performanță, consultați Servere FDC.