Flusso di elaborazione HTTP di Nginx: ottimizzazione della configurazione

La configurazione predefinita di Nginx è progettata per garantire la compatibilità, non le prestazioni. Con una messa a punto adeguata, un singolo server può gestire da 50.000 a 80.000 richieste al secondo. Questa guida illustra le impostazioni più importanti: processi di lavoro, connessioni, keepalive, buffering, bilanciamento del carico e come verificare le modifiche apportate tramite benchmark.

Come Nginx elabora le richieste HTTP

Nginx gestisce le richieste in fasi distinte, ciascuna delle quali consuma risorse di sistema. Comprendere il flusso aiuta a individuare le impostazioni giuste.

Si parte dal livello del kernel. Le connessioni in entrata finiscono nelle code SYN e ACCEPT e vengono raccolte dai processi worker di Nginx. Una volta accettata, il worker analizza la richiesta HTTP dal buffer del kernel. Il traffico TLS rende questo passaggio più impegnativo per la CPU.

Successivamente, Nginx abbina la richiesta a un server virtuale utilizzando l'intestazione Host e la combinazione IP/porta, quindi risolve l'URI in un blocco di posizione tramite corrispondenza di prefissi o espressioni regolari.

Per i contenuti dinamici, Nginx inoltra la richiesta a un backend (FastCGI, proxy). Questa fase di comunicazione a monte trae grande vantaggio dalle connessioni persistenti. Senza il keepalive a monte, Nginx apre una nuova connessione TCP per ogni richiesta, aumentando la latenza e il carico della CPU.

Se proxy_buffering è abilitato, Nginx legge l’intera risposta a monte in memoria prima di consegnarla al client. Questo libera il worker per gestire immediatamente nuove richieste. Infine, durante la consegna dell’output, abilitare sendfile consente trasferimenti zero-copy, che possono far salire la velocità effettiva da circa 6 Gbps a 30 Gbps.

Ogni fase consuma buffer di memoria, descrittori di file e cicli di CPU. Le sezioni seguenti affrontano ciascun collo di bottiglia.

Processi di lavoro e connessioni

Inizia con worker_processes auto; nel contesto principale. In questo modo il numero di worker corrisponderà ai core della CPU. Su un VPS con un numero limitato di core, impostare il numero manualmente (ad es. worker_processes 2;). Se il carico di lavoro richiede molta memoria, valuta la possibilità di ridurre il numero di worker per evitare un sovraccarico della RAM.

Abilita worker_cpu_affinity auto; per associare ogni worker a un core specifico. Questo riduce i cache miss e il cambio di contesto. Disponibile a partire da Nginx 1.9.10.

Limiti di connessione

La worker_connections imposta il numero di connessioni simultanee che ogni worker può gestire. La capacità totale è worker_processes × worker_connections. Il valore predefinito di 512 o 1.024 è troppo basso per l'ambiente di produzione. Impostalo su 2.048 o 4.096 per worker per i siti ad alto traffico.

Ogni connessione richiede almeno un descrittore di file. In una configurazione con proxy inverso, ogni connessione ne utilizza due (uno per il client, uno per l’upstream). Impostare worker_rlimit_nofile un valore pari ad almeno il doppio del worker_connections valore con un margine di sicurezza. Per worker_connections 4096;, utilizzare worker_rlimit_nofile 10000; o superiore.

A livello di sistema, aumentare fs.file-max in /etc/sysctl.conf ad almeno 500.000 e imposta LimitNOFILE=65535.

Infine, aggiungi multi_accept on; nel blocco events in modo che i worker accettino tutte le connessioni in sospeso contemporaneamente anziché una alla volta.

Timeout e Keepalive

Keepalive client

La keepalive_timeout direttiva controlla per quanto tempo le connessioni client inattive rimangono aperte. Per i server ad alto traffico, un intervallo compreso tra 30 e 65 secondi funziona bene. Utilizza la forma a due parametri:

keepalive_timeout 65s 60s;

Il primo valore è il timeout lato server. Il secondo invia un Keep-Alive: timeout=60 header al client. Impostare il valore client leggermente più basso previene le condizioni di competizione in cui i browser tentano di riutilizzare connessioni che Nginx ha già chiuso.

La keepalive_requests limita il numero di richieste che una singola connessione può gestire prima di essere chiusa. Il valore predefinito è 1.000 (aumentato da 100 nella versione 1.19.10). Per i backend stabili, aumentarlo a 10.000 per ridurre il turnover delle connessioni.

I timeout del proxy

proxy_connect_timeout imposta per quanto tempo Nginx attende per stabilire una connessione con il backend. Il valore predefinito è 60 secondi. Riducilo a 5-10 secondi per un failover veloce.

proxy_read_timeout definisce per quanto tempo Nginx attende tra letture successive dall'upstream. Allinearlo al timeout di esecuzione del backend. Se quello di PHP-FPM request_terminate_timeout è di 120 secondi, impostare proxy_read_timeout ad almeno 120 secondi per evitare errori 504 prematuri.

proxy_send_timeout controlla l'intervallo tra le scritture successive all'upstream. Il valore predefinito di 60 secondi va bene di solito a meno che non si stiano inviando corpi di richiesta di grandi dimensioni.

Di norma, proxy_connect_timeout dovrebbe sempre essere il più breve dei tre.

Dimensione del buffer

client_body_buffer_size controlla la quantità di corpo di una richiesta in entrata che Nginx trattiene in memoria. Il valore predefinito di 8k o 16k gestisce semplici invii di moduli, ma i caricamenti di file andranno a finire sul disco. Aumentalo a 128k per caricamenti di piccole-medie dimensioni. Aumenta client_max_body_size il valore predefinito di 1 MB se gli utenti caricano file più grandi.

proxy_buffer_size gestisce le intestazioni di risposta separatamente dal corpo. Il valore predefinito di 4k o 8k di solito funziona, ma le applicazioni con grandi Set-Cookie (comune nell'e-commerce) possono superarlo, causando errori 502. Misurate la dimensione effettiva delle vostre intestazioni:

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

arrotondate per eccesso all'incremento di 4k più vicino.

proxy_buffers imposta il numero e la dimensione dei buffer per il corpo della risposta. L'impostazione predefinita (8 buffer da 4k o 8k, per un totale da 32k a 64k) non è sufficiente per una risposta JSON di grandi dimensioni. Misurate la vostra risposta tipica più grande con curl e configura un numero di buffer sufficiente a mantenerla interamente in RAM.

Comportamento del buffering del proxy

Con proxy_buffering on (impostazione predefinita), Nginx legge l'intera risposta upstream in memoria prima di inviarla al client. Ciò consente ai server backend di passare immediatamente a nuove richieste.

Impostare proxy_busy_buffers_size ad almeno proxy_buffer_size più un buffer, ma meno del pool di buffer totale. Per proxy_buffers 8 16k (128k in totale), mantenere proxy_busy_buffers_size al di sotto di 112k.

Per gli endpoint in tempo reale come gli eventi inviati dal server o il long-polling, disabilitare il buffering proxy_buffering off in un blocco specifico per la posizione. Applicare questo selettivamente a /stream o /events , non a livello globale.

Bilanciamento del carico e keepalive upstream

Per impostazione predefinita, Nginx apre una nuova connessione TCP per ogni richiesta proxy. Ogni handshake aggiunge da 10 a 100 ms di latenza, con TLS che aggiunge altri 10-50 ms. L'upstream keepalive mantiene un pool di connessioni persistenti per eliminare questo sovraccarico.

Sono necessarie tre impostazioni:

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

Il keepalive imposta il numero massimo di connessioni inattive per worker. Calcolare la dimensione ottimale del pool come: (workers × target concurrency) / upstream nodes.

Imposta l'upstream keepalive_timeout tra 60 e 120 secondi per adattarlo alle impostazioni del backend e gestire i picchi di traffico.

Strategie di bilanciamento

Nginx supporta diversi metodi di bilanciamento del carico. Round-robin (l'impostazione predefinita) distribuisce le richieste in modo sequenziale. least_conn indirizza al server con il minor numero di connessioni attive, il che si adatta a carichi di lavoro con durate delle richieste variabili. ip_hash garantisce la persistenza della sessione indirizzando lo stesso IP del client allo stesso backend.

Utilizza il weight parametro quando i server hanno capacità diverse:

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

Il server ponderato riceve il triplo del traffico. Il backup server si attiva solo se tutti i server primari sono inattivi. Configurare max_fails e fail_timeout per i controlli di integrità passivi e utilizzare max_conns per limitare le connessioni simultanee per backend.

Test e monitoraggio

Misurate sempre le prestazioni di base prima di apportare qualsiasi modifica. Dopo ogni modifica, eseguite nuovamente il benchmark. Apportate una modifica alla volta.

Convalida la sintassi della configurazione con nginx -t prima di ricaricare. Eseguire i benchmark da una macchina separata per evitare la contesa delle risorse.

wrk è lo strumento standard per i test di carico HTTP:

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

Tieni traccia delle richieste al secondo, della latenza media, della latenza massima e della velocità di trasferimento. Apache Bench funziona per test più semplici:

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

Monitoraggio continuo

Abilita il stub_status modulo per monitorare le connessioni attive in tempo reale tramite curl http://localhost/nginx_status.

Aggiungi variabili di temporizzazione al tuo formato di log per identificare dove si verificano i ritardi:

• $request_time per la durata totale della richiesta
• $upstream_connect_time per il tempo di connessione al backend
• $upstream_response_time per il tempo totale di elaborazione del backend

Controlla i log degli errori per individuare eventuali problemi di buffer con journalctl -u nginx --no-pager | grep "temporary file". Se le risposte vengono scritte su disco, il tuo proxy_buffers sono troppo piccole. Cerca gli errori "troppi file aperti", che indicano worker_rlimit_nofile deve essere aumentata.

Riduci l'I/O dei log con la registrazione in buffer:

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

Utilizza ss -tn state established dst [backend_ip] durante i test di carico per verificare che le connessioni vengano riutilizzate e non si accumulino in TIME_WAIT.

Per i server dedicati e l'hosting VPS ottimizzati per carichi di lavoro ad alte prestazioni, consultare FDC Servers.