Nginx HTTP-verwerkingsstroom: configuratie-afstemming

De standaardconfiguratie van Nginx is ontworpen met het oog op compatibiliteit, niet op prestaties. Met de juiste afstemming kan een enkele server 50.000 tot 80.000 verzoeken per seconde verwerken. Deze gids behandelt de instellingen die het belangrijkst zijn: worker-processen, verbindingen, keepalive, buffering, load balancing en hoe u uw wijzigingen kunt verifiëren met benchmarks.

Hoe Nginx HTTP-verzoeken verwerkt

Nginx verwerkt verzoeken in verschillende fasen, die elk systeembronnen verbruiken. Als u de workflow begrijpt, kunt u de juiste instellingen kiezen.

Het begint op kernelniveau. Inkomende verbindingen komen terecht in SYN- en ACCEPT-wachtrijen, waarna ze worden opgepikt door Nginx-werkprocessen. Zodra een verzoek is geaccepteerd, parseert het werkproces het HTTP-verzoek uit de kernelbuffer. TLS-verkeer maakt deze stap CPU-intensiever.

Vervolgens koppelt Nginx het verzoek aan een virtuele server met behulp van de Host-header en de combinatie van IP en poort, en vertaalt vervolgens de URI naar een locatieblok via prefix- of regex-matching.

Voor dynamische inhoud stuurt Nginx het verzoek door naar een backend (FastCGI, proxy). Deze upstream-communicatiefase profiteert sterk van persistente verbindingen. Zonder upstream keepalive opent Nginx een nieuwe TCP-verbinding per verzoek, wat leidt tot extra vertraging en CPU-overhead.

Als proxy_buffering is ingeschakeld, leest Nginx het volledige upstream-antwoord in het geheugen voordat het aan de client wordt geleverd. Dit maakt de worker vrij om onmiddellijk nieuwe verzoeken te verwerken. Ten slotte, tijdens de levering van de output, maakt het inschakelen van sendfile zero-copy-overdrachten mogelijk, wat de doorvoer kan verhogen van ongeveer 6 Gbps naar 30 Gbps.

Elke fase verbruikt geheugenbuffers, bestandsdescriptoren en CPU-cycli. De onderstaande secties richten zich op elke bottleneck.

Werkprocessen en verbindingen

Begin met worker_processes auto; in uw hoofdcontext. Dit stemt het aantal workers af op uw CPU-kernen. Stel op een VPS met een beperkt aantal kernen het aantal handmatig in (bijv. worker_processes 2;). Als uw workload veel geheugen vereist, overweeg dan het aantal workers te verlagen om overbelasting van het RAM-geheugen te voorkomen.

Schakel worker_cpu_affinity auto; om elke worker aan een specifieke core te koppelen. Dit vermindert cache-misses en contextwisselingen. Beschikbaar sinds Nginx 1.9.10.

Verbindingslimieten

De worker_connections -richtlijn bepaalt hoeveel gelijktijdige verbindingen elke worker aankan. De totale capaciteit is worker_processes × worker_connections. De standaardwaarde van 512 of 1.024 is te laag voor productieomgevingen. Stel deze in op 2.048 of 4.096 per worker voor sites met veel verkeer.

Elke verbinding heeft ten minste één bestandsdescriptor nodig. In een reverse-proxy-opstelling gebruikt elke verbinding er twee (één voor de client, één voor de upstream). Stel worker_rlimit_nofile de waarde op ten minste het dubbele van uw worker_connections waarde met wat speling. Voor worker_connections 4096;, gebruik worker_rlimit_nofile 10000; of hoger.

Verhoog op systeemniveau fs.file-max in /etc/sysctl.conf tot ten minste 500.000 en stel systemd's LimitNOFILE=65535.

Voeg ten slotte multi_accept on; in het events-blok toe, zodat workers alle wachtende verbindingen in één keer accepteren in plaats van één voor één.

Time-outs en Keepalive

Keepalive van de client

De keepalive_timeout richtlijn bepaalt hoe lang inactieve clientverbindingen open blijven. Voor servers met veel verkeer werkt 30 tot 65 seconden goed. Gebruik de vorm met twee parameters:

keepalive_timeout 65s 60s;

De eerste waarde is de time-out aan de serverzijde. De tweede stuurt een Keep-Alive: timeout=60 header naar de client. Door de clientwaarde iets lager in te stellen, voorkomt u race-condities waarbij browsers verbindingen proberen te hergebruiken die Nginx al heeft gesloten.

De keepalive_requests -richtlijn beperkt het aantal verzoeken dat een enkele verbinding verwerkt voordat deze wordt beëindigd. De standaardwaarde is 1.000 (verhoogd van 100 in versie 1.19.10). Verhoog dit voor stabiele backends naar 10.000 om het aantal verbindingsovergangen te verminderen.

Proxy-time-outs

proxy_connect_timeout bepaalt hoe lang Nginx wacht om een verbinding met de backend tot stand te brengen. De standaardinstelling is 60 seconden. Verlaag dit naar 5 tot 10 seconden voor snelle failover.

proxy_read_timeout bepaalt hoe lang Nginx wacht tussen opeenvolgende leesbewerkingen van de upstream. Stem dit af op de uitvoeringstime-out van uw backend. Als die van PHP-FPM request_terminate_timeout 120 seconden is, stel proxy_read_timeout op minimaal 120 seconden om voortijdige 504-fouten te voorkomen.

proxy_send_timeout regelt het interval tussen opeenvolgende schrijfbewerkingen naar de upstream. De standaardinstelling van 60 seconden is meestal prima, tenzij u grote verzoekteksten verstuurt.

In de regel proxy_connect_timeout altijd de kortste van de drie zijn.

Buffer Sizing

client_body_buffer_size bepaalt hoeveel van de body van een binnenkomend verzoek Nginx in het geheugen vasthoudt. De standaardinstelling van 8k of 16k is voldoende voor eenvoudige formulierverzendingen, maar het uploaden van bestanden zal naar de schijf worden doorgeschoven. Verhoog deze naar 128k voor kleine tot middelgrote uploads. Verhoog client_max_body_size de standaardwaarde van 1 MB als gebruikers grotere bestanden uploaden.

proxy_buffer_size verwerkt response headers apart van de body. De standaardwaarde van 4k of 8k werkt meestal, maar applicaties met grote Set-Cookie headers (gebruikelijk in e-commerce) kunnen deze limiet overschrijden, wat 502-fouten veroorzaakt. Meet de werkelijke grootte van uw headers:

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

Rond af naar het dichtstbijzijnde veelvoud van 4k.

proxy_buffers stelt het aantal en de grootte van de buffers voor de responsbody in. De standaardinstelling (8 buffers van 4k of 8k, in totaal 32k tot 64k) is niet groot genoeg voor een grote JSON-respons. Meet uw grootste typische respons en curl en configureer voldoende buffers om het volledig in het RAM-geheugen te houden.

Gedrag van proxy-buffering

Met proxy_buffering on (de standaardinstelling) leest Nginx het volledige upstream-antwoord in het geheugen voordat het naar de client wordt verzonden. Hierdoor kunnen backend-servers onmiddellijk doorgaan met nieuwe verzoeken.

Stel proxy_busy_buffers_size in op ten minste proxy_buffer_size plus één buffer, maar minder dan je totale bufferpool. Voor proxy_buffers 8 16k (128k totaal), houd proxy_busy_buffers_size minder dan 112k.

Schakel voor realtime-eindpunten zoals Server-Sent Events of long-polling buffering uit proxy_buffering off in een locatiespecifiek blok. Pas dit selectief toe op /stream of /events paden, niet globaal.

Load Balancing en Upstream Keepalive

Standaard opent Nginx een nieuwe TCP-verbinding voor elk verzoek dat via de proxy wordt verzonden. Elke handshake voegt 10 tot 100 ms latentie toe, waarbij TLS nog eens 10 tot 50 ms toevoegt. Upstream keepalive onderhoudt een pool van permanente verbindingen om deze overhead te elimineren.

Er zijn drie instellingen vereist:

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

De keepalive waarde stelt het maximum aantal inactieve verbindingen per worker in. Bereken de optimale poolgrootte als: (workers × target concurrency) / upstream nodes.

Stel upstream keepalive_timeout in op 60 tot 120 seconden om aan te sluiten bij de instellingen van uw backend en pieken in het verkeer op te vangen.

Strategieën voor het verdelen van de belasting

Nginx ondersteunt verschillende methoden voor load balancing. Round-robin (de standaardinstelling) verdeelt verzoeken sequentieel. least_conn Routes naar de server met de minste actieve verbindingen, wat geschikt is voor workloads met variabele verzoekduur. ip_hash biedt sessiepersistentie door hetzelfde client-IP-adres naar dezelfde backend te routeren.

Gebruik de weight parameter wanneer servers verschillende capaciteiten hebben:

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

De gewogen server ontvangt drie keer zoveel verkeer. De backup server wordt alleen geactiveerd als alle primaire servers uitvallen. Configureer max_fails en fail_timeout voor passieve statuscontroles, en gebruik max_conns om het aantal gelijktijdige verbindingen per backend te beperken.

Testen en monitoren

Meet altijd de basisprestaties voordat u iets wijzigt. Voer na elke wijziging opnieuw een benchmark uit. Breng één wijziging per keer aan.

Valideer de syntaxis van uw configuratie met nginx -t voordat u herlaadt. Voer benchmarks uit vanaf een aparte machine om concurrentie om bronnen te voorkomen.

wrk is de standaardtool voor HTTP-belastingstests:

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

Houd het aantal verzoeken per seconde, de gemiddelde latentie, de maximale latentie en de overdrachtssnelheid bij. Apache Bench is geschikt voor eenvoudigere tests:

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

Doorlopende monitoring

Schakel de stub_status module in om actieve verbindingen in realtime te monitoren via curl http://localhost/nginx_status.

Voeg timingvariabelen toe aan uw logformaat om te bepalen waar vertragingen optreden:

• $request_time voor de totale verzoekduur
• $upstream_connect_time voor de backend-verbindingstijd
• $upstream_response_time voor de totale verwerkingstijd van de backend

Controleer de foutenlogboeken op bufferproblemen met journalctl -u nginx --no-pager | grep "temporary file". Als reacties de schijf raken, zijn uw proxy_buffers te klein. Zoek naar fouten van het type "too many open files", die aangeven worker_rlimit_nofile moet worden verhoogd.

Verminder log-I/O met gebufferde logboekregistratie:

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

Gebruik ss -tn state established dst [backend_ip] tijdens belastingstests om te controleren of verbindingen worden hergebruikt en zich niet opstapelen in TIME_WAIT.

Zie FDC-servers voor dedicated servers en VPS-hosting die zijn geoptimaliseerd voor high-performance workloads.