Nginx HTTP-töötlemise voog: konfiguratsiooni häälestamine

Nginx'i vaikimisi konfiguratsioon on loodud ühilduvuse, mitte jõudluse jaoks. Õige häälestamisega suudab üks server töödelda 50 000 kuni 80 000 päringut sekundis. Käesolev juhend käsitleb kõige olulisemaid seadeid: tööprotsesse, ühendusi, keepalive'i, puhverdamist, koormuse jaotamist ning seda, kuidas oma muudatusi võrdlusandmetega kontrollida.

Kuidas Nginx töötleb HTTP-päringuid

Nginx töötleb päringuid erinevates faasides, millest igaüks tarbib süsteemi ressursse. Protsessi mõistmine aitab teil valida õiged seaded.

See algab tuuma tasandil. Sissetulevad ühendused jõuavad SYN- ja ACCEPT-järjekordadesse ning Nginx-i tööprotsessid võtavad need vastu. Kui päring on vastu võetud, analüüsib tööprotsess HTTP-päringut tuumapuhvrist. TLS-liiklus muudab selle sammu CPU-le koormavamaks.

Seejärel sobitab Nginx päringu virtuaalserveriga, kasutades Host-pealkirja ja IP/porti kombinatsiooni, ning lahendab URI asukohablokiks eelneva või regulaaravaldise sobitamise abil.

Dünaamilise sisu puhul edastab Nginx päringu tagapõhja (FastCGI, proxy). See ülesvoolu kommunikatsiooni faas saab püsivühendustest suurt kasu. Ilma ülesvoolu keepalive'ita avab Nginx iga päringu jaoks uue TCP-ühenduse, mis suurendab latentsust ja CPU koormust.

Kui proxy_buffering on lubatud, loeb Nginx kogu ülesvoolu vastuse mällu enne selle edastamist kliendile. See vabastab töötaja, et ta saaks kohe uusi päringuid töödelda. Lõpuks, väljundi edastamise ajal, lubab sendfile võimaldab null-koopia ülekandeid, mis võivad suurendada läbilaskevõimet umbes 6 Gbps-lt 30 Gbps-ni.

Iga faas tarbib mälupuhvreid, failideskriptoreid ja CPU tsükleid. Allpool olevad jaotised käsitlevad iga kitsaskohta.

Tööprotsessid ja ühendused

Alusta worker_processes auto; peamises kontekstis. See sobitab töötajate arvu teie CPU tuumadega. Piiratud tuumadega VPS-il seadke number käsitsi (nt worker_processes 2;). Kui teie töökoormus on mälumahukas, kaaluge töötajate arvu vähendamist, et vältida RAM-i ülekoormamist.

Lülita sisse worker_cpu_affinity auto; , et seostada iga töötaja kindla tuumaga. See vähendab vahemälust möödalaskmisi ja konteksti vahetamist. Saadaval alates Nginx 1.9.10 versioonist.

Ühenduste piirangud

Direktiiv worker_connections määrab, kui palju samaaegseid ühendusi iga töötaja suudab hallata. Kogumahutavus on worker_processes × worker_connections. Vaikimisi väärtus 512 või 1024 on tootmiskeskkonnas liiga madal. Määrake see suure liiklusega saitide puhul 2048 või 4096 töötaja kohta.

Iga ühendus vajab vähemalt ühte faili deskriptorit. Pöördproksi seadistuses kasutab iga ühendus kahte (üks kliendile, teine ülesvoolule). Määrake worker_rlimit_nofile väärtus vähemalt kahekordseks worker_connections väärtusele, jättes varu. worker_connections 4096;, kasutage worker_rlimit_nofile 10000; või suuremat väärtust.

Süsteemi tasandil suurendage fs.file-max väärtust /etc/sysctl.conf vähemalt 500 000 ja seadke systemd LimitNOFILE=65535.

Lõpuks lisage multi_accept on; sündmuste plokki, et töötajad aktsepteeriksid kõik ootavad ühendused korraga, mitte ükshaaval.

Ajalõpp ja Keepalive

Kliendi keepalive

Direktiiv keepalive_timeout direktiiv määrab, kui kaua jäävad avatuks kasutamata kliendiühendused. Suure liiklusega serverite puhul sobib hästi 30–65 sekundit. Kasutage kaheparameetrilist vormi:

keepalive_timeout 65s 60s;

Esimene väärtus on serveripoolne aegumine. Teine saadab Keep-Alive: timeout=60 pealkirja kliendile. Kliendi väärtuse veidi madalamaks seadmine aitab vältida võidujooksuolukordi, kus brauserid üritavad taaskasutada ühendusi, mille Nginx on juba sulgenud.

Direktiiv keepalive_requests direktiiv piirab, kui palju päringuid üks ühendus enne sulgemist töötleb. Vaikimisi on see 1000 (tõstetud 100-lt versioonis 1.19.10). Stabiilsete tagapõhjade puhul suurendage seda 10 000-ni, et vähendada ühenduste vahetumist.

Proxy ooteajad

proxy_connect_timeout määrab, kui kaua Nginx ootab ühenduse loomist backendiga. Vaikimisi on see 60 sekundit. Vähendage seda 5–10 sekundini kiireks failoveriks.

proxy_read_timeout määrab, kui kaua Nginx ootab järjestikuste lugemiste vahel ülesvoolust. Kohandage seda oma tagapõhja täitmise ooteajaga. Kui PHP-FPM-i request_terminate_timeout on 120 sekundit, seadke proxy_read_timeout vähemalt 120 sekundiks, et vältida enneaegseid 504-vigu.

proxy_send_timeout kontrollib intervalli järjestikuste kirjutamiste vahel ülesvoolu. Vaikimisi 60 sekundit on tavaliselt piisav, kui te ei saada suuri päringute sisu.

Reeglina proxy_connect_timeout peaks alati olema kolmest lühim.

Puhvri suurus

client_body_buffer_size määrab, kui palju sissetulevast päringu sisust Nginx mällu hoiab. Vaikimisi 8k või 16k suudab käidelda lihtsaid vormide saatmisi, kuid failide üleslaadimisel läheb osa andmetest kettale. Suurendage seda väikeste ja keskmise suurusega üleslaadimiste puhul 128k-ni. Suurendage client_max_body_size seda vaikimisi väärtusest 1 MB, kui kasutajad laadivad üles suuremaid faile.

proxy_buffer_size käsitleb vastuse päiseid eraldi sisust. Vaikimisi 4k või 8k töötab tavaliselt, kuid rakendused suure Set-Cookie pealkirjadega rakendused (tavaline e-kaubanduses) võivad seda ületada, põhjustades 502-vigu. Mõõtke oma tegelikku pealkirja suurust:

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

ümmardage lähima 4k suuruse juurde.

proxy_buffers määrab vastuse sisu puhvrite arvu ja suuruse. Vaikimisi (8 puhvrit suurusega 4k või 8k, kokku 32k kuni 64k) ei mahuta suurt JSON-vastust. Mõõtke oma suurimat tüüpilist vastust curl ja seadistage piisavalt puhvreid, et see mahuks täielikult RAM-i.

Proksi puhverdamise käitumine

Kui proxy_buffering on (vaikimisi), loeb Nginx kogu ülesvoolu vastuse mällu enne selle saatmist kliendile. See võimaldab tagapõhjaserveritel kohe uute päringutega edasi minna.

Määrake proxy_busy_buffers_size väärtuseks vähemalt proxy_buffer_size pluss üks puhver, kuid vähem kui teie kogu puhvripool. proxy_buffers 8 16k (kokku 128k), hoidke proxy_busy_buffers_size alla 112k.

Reaalajas lõpppunktide puhul, nagu Server-Sent Events või pikk küsitlemine, lülitage puhverdamine välja proxy_buffering off asukohaspetsiifilises plokis. Rakendage seda valikuliselt /stream või /events teedele, mitte globaalselt.

Koormuse tasakaalustamine ja ülesvoolu keepalive

Vaikimisi avab Nginx iga proksitud päringu jaoks uue TCP-ühenduse. Iga käepigistus lisab 10–100 ms viivitust, millele TLS lisab veel 10–50 ms. Upstream keepalive hoiab püsivate ühenduste kogumit, et kõrvaldada see lisakoormus.

Vaja on kolme seadet:

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

Seade keepalive väärtus määrab töötaja kohta maksimaalse ooteseisundi ühenduste arvu. Optimaalse reservi suuruse arvutamiseks kasutage valemit: (workers × target concurrency) / upstream nodes.

Määrake ülesvoolu keepalive_timeout väärtuseks 60–120 sekundit, et see vastaks teie backendi seadetele ja suudaks toime tulla liikluse tippkoormustega.

Tasakaalustamisstrateegiad

Nginx toetab mitmeid koormuse jaotamise meetodeid. Round-robin (vaikimisi) jaotab päringud järjest. least_conn suunab serverisse, millel on kõige vähem aktiivseid ühendusi, mis sobib töökoormustega, kus päringute kestus on muutuv. ip_hash Tagab seansi püsivuse, suunates sama kliendi IP-aadressi samale backendile.

Kasutage weight parameetrit, kui serveritel on erinev võimsus:

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

Kaalutud server saab kolm korda rohkem liiklust. backup server aktiveerub ainult siis, kui kõik esmased serverid on maas. Konfigureerige max_fails ja fail_timeout passiivseks tervisekontrolliks ning kasutage max_conns , et piirata samaaegseid ühendusi backend'i kohta.

Testimine ja seire

Mõõtke alati baasjõudlust enne mis tahes muudatuste tegemist. Pärast iga muudatust tehke uuesti võrdlusmõõtmine. Tehke üks muudatus korraga.

Kontrollige oma konfiguratsiooni süntaksit nginx -t enne uuesti laadimist. Jooksutage võrdlustestid eraldi masinalt, et vältida ressursside konkurentsi.

wrk on standardne tööriist HTTP koormustestide tegemiseks:

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

Jälgige päringuid sekundis, keskmist latentsust, maksimaalset latentsust ja andmeedastuskiirust. Apache Bench sobib lihtsamateks testideks:

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

Jätkuv seire

Lülita sisse stub_status moodul, et jälgida aktiivseid ühendusi reaalajas curl http://localhost/nginx_status.

Lisage oma logiformaati ajastusmuutujad, et tuvastada, kus viivitused tekivad:

• $request_time kogu päringu kestuse jaoks
• $upstream_connect_time tagapõhja ühenduse aja jaoks
• $upstream_response_time tagapõhja töötlemise koguaeg

Kontrollige vealogisid puhvri probleemide suhtes journalctl -u nginx --no-pager | grep "temporary file". Kui vastused jõuavad kettale, on teie proxy_buffers on liiga väikesed. Otsige vigu "too many open files", mis viitavad worker_rlimit_nofile suurendamist.

Vähendage logi sisend-väljundoperatsioone puhverdatud logimisega:

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

Kasutage ss -tn state established dst [backend_ip] koormustestide ajal, et veenduda, et ühendusi kasutatakse uuesti ja need ei kuhju TIME_WAIT-seisundisse.

Kõrge jõudlusega töökoormuste jaoks optimeeritud pühendatud serverite ja VPS-hostingu kohta vaadake FDC-servereid.