Lista di controllo essenziale per l'ottimizzazione delle prestazioni di Nginx per siti web ad alto traffico

Per qualsiasi sito web che registri un traffico significativo, Nginx si distingue come un server web e un reverse proxy potente e altamente efficiente. Tuttavia, la semplice implementazione di Nginx non è sufficiente a garantire prestazioni ottimali sotto carico pesante. Una configurazione e una messa a punto appropriate sono fondamentali per sbloccare il suo pieno potenziale, assicurando che le vostre applicazioni web rimangano veloci, reattive e affidabili.

Questo articolo fornisce una lista di controllo completa delle principali configurazioni e direttive di Nginx specificamente progettate per ottimizzare le prestazioni in ambienti ad alto traffico. Tratteremo tutto, dalla gestione dei processi worker e delle connessioni alla messa a punto dei buffer, all'implementazione di solide strategie di caching e all'ottimizzazione della compressione. Affrontando sistematicamente queste aree, potrete ridurre significativamente il carico del server, migliorare la velocità di consegna dei contenuti e migliorare l'esperienza utente complessiva.

1. Ottimizzare i processi worker e le connessioni

Nginx sfrutta un modello di processi master-worker. Il processo master legge la configurazione e gestisce i processi worker, che gestiscono le richieste client effettive. Una corretta configurazione di questi può migliorare drasticamente la concorrenza e l'utilizzo delle risorse.

worker_processes

Questa direttiva determina quanti processi worker Nginx genererà. Generalmente, impostarla su auto consente a Nginx di rilevare il numero di core della CPU e di generare un numero uguale di processi worker, che è una pratica comune e raccomandata.

worker_connections

Definisce il numero massimo di connessioni simultanee che un singolo processo worker può aprire. Questa impostazione, in combinazione con worker_processes, determina il numero totale teorico di connessioni concorrenti che Nginx può gestire (worker_processes * worker_connections).

multi_accept

Abilita un processo worker ad accettare più nuove connessioni contemporaneamente, prevenendo potenziali colli di bottiglia sotto carico elevato.

# /etc/nginx/nginx.conf

worker_processes auto; # Solitamente impostato su 'auto' o sul numero di core della CPU

events {
    worker_connections 1024; # Regolare in base alla capacità del server e al carico previsto
    multi_accept on;
}

Suggerimento: Monitorate l'utilizzo della CPU del vostro server. Se worker_processes è impostato su auto e l'utilizzo della CPU è costantemente elevato, potreste considerare di aumentare worker_connections o di scalare le risorse del server.

2. Gestione efficiente delle connessioni

L'ottimizzazione del modo in cui Nginx gestisce le connessioni di rete può ridurre il sovraccarico e migliorare la reattività.

keepalive_timeout

Specifica per quanto tempo una connessione client keep-alive rimarrà aperta. Il riutilizzo delle connessioni riduce il sovraccarico derivante dallo stabilire nuove connessioni TCP e handshake SSL. Un valore comune è 15-65 secondi, a seconda dell'interattività della vostra applicazione.

sendfile

Abilita il trasferimento diretto dei dati tra descrittori di file, bypassando il buffering dello spazio utente. Questo migliora significativamente le prestazioni durante la gestione di file statici.

tcp_nopush

Funziona con sendfile. Nginx tenta di inviare l'intestazione HTTP e l'inizio del file in un unico pacchetto. Successivamente, invia i dati in pacchetti completi. Questo riduce il numero di pacchetti inviati.

tcp_nodelay

Istruisce Nginx a inviare i dati non appena sono disponibili, senza buffering. Questo è vantaggioso per le applicazioni interattive dove la bassa latenza è più critica della massimizzazione del throughput (ad esempio, applicazioni di chat o aggiornamenti in tempo reale).

http {
    keepalive_timeout 65; # Connessioni keep-alive per 65 secondi
    sendfile on;
    tcp_nopush on; # Richiede sendfile on
    tcp_nodelay on; # Utile per il proxy di contenuti dinamici
}

3. Ottimizzazione dei buffer

Nginx utilizza buffer per gestire le richieste client e le risposte dai server upstream (come i server applicativi). Dimensionare correttamente questi buffer può prevenire I/O su disco non necessari, ridurre l'utilizzo della memoria e migliorare il throughput.

Buffer client

• client_body_buffer_size: Dimensione del buffer per i corpi delle richieste client. Se un corpo supera questa dimensione, viene scritto in un file temporaneo.
• client_header_buffer_size: Dimensione del buffer per la prima riga e le intestazioni di una richiesta client.
• large_client_header_buffers: Definisce il numero e la dimensione di buffer più grandi per la lettura delle intestazioni delle richieste client. Utile per richieste con molti cookie o intestazioni referer lunghe.

Buffer proxy (per configurazioni reverse proxy)

• proxy_buffers: Il numero e la dimensione dei buffer utilizzati per leggere le risposte dal server proxato.
• proxy_buffer_size: La dimensione del primo buffer per la lettura della risposta. Tipicamente più piccolo, poiché spesso contiene solo le intestazioni.
• proxy_busy_buffers_size: La quantità massima di buffer di risposta che possono essere nello stato 'occupato' (attivamente inviati al client) in un dato momento.

Buffer FastCGI (per PHP-FPM, ecc.)

• fastcgi_buffers: Il numero e la dimensione dei buffer utilizzati per leggere le risposte dal server FastCGI.
• fastcgi_buffer_size: La dimensione del primo buffer per la lettura della risposta.

http {
    # Buffer client
    client_body_buffer_size 1M; # Regolare in base alla dimensione prevista del corpo della richiesta (es. caricamento file)
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k; # 4 buffer, ciascuno da 8KB

    # Buffer proxy (se Nginx agisce come reverse proxy)
    proxy_buffers 8 16k; # 8 buffer, ciascuno da 16KB
    proxy_buffer_size 16k; # Primo buffer da 16KB
    proxy_busy_buffers_size 16k; # Max 16KB di buffer occupati

    # Buffer FastCGI (se Nginx lavora con PHP-FPM)
    fastcgi_buffers 116 8k; # 116 buffer, ciascuno da 8KB (es. per WordPress)
    fastcgi_buffer_size 16k; # Primo buffer da 16KB
}

Avvertenza: Impostare i buffer troppo piccoli può portare a I/O su disco e degrado delle prestazioni. Impostarli troppo grandi può consumare memoria eccessiva. Trovare un equilibrio tramite test.

4. Implementare strategie di caching robuste

La memorizzazione nella cache è uno dei modi più efficaci per migliorare le prestazioni e ridurre il carico sui vostri server backend. Nginx può fungere da potente cache di contenuti.

proxy_cache_path

Definisce il percorso della directory della cache, la sua dimensione, il numero di livelli di sottodirectory e per quanto tempo gli elementi inattivi rimangono nella cache.

proxy_cache

Attiva la memorizzazione nella cache per un dato blocco location, facendo riferimento alla zona definita in proxy_cache_path.

proxy_cache_valid

Imposta il tempo per il quale Nginx dovrebbe memorizzare nella cache le risposte con specifici codici di stato HTTP.

proxy_cache_revalidate

Quando abilitato, Nginx utilizzerà le intestazioni If-Modified-Since e If-None-Match per riconvalidare il contenuto memorizzato nella cache con il backend, riducendo l'utilizzo della larghezza di banda.

proxy_cache_use_stale

Istruisce Nginx a servire contenuti obsoleti dalla cache se il server backend è inattivo, non risponde o sta riscontrando errori. Questo migliora notevolmente la disponibilità.

expires

Imposta le intestazioni Cache-Control e Expires per la memorizzazione nella cache lato client dei file statici. Ciò minimizza le richieste ripetute a Nginx.

http {
    # Definisce una zona di cache proxy nel blocco http
    proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=10g;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_upstream_backend;
            proxy_cache my_cache; # Abilita la cache per questa location
            proxy_cache_valid 200 302 10m; # Cache risposte di successo per 10 minuti
            proxy_cache_valid 404 1m; # Cache 404 per 1 minuto
            proxy_cache_revalidate on;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X-Cache-Status $upstream_cache_status; # Aiuta con il debug
        }

        # Cache i file statici nel browser per un periodo più lungo
        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            expires 30d; # Cache per 30 giorni
            add_header Cache-Control "public, no-transform";
            # Per i file statici, considerare di servirli direttamente da Nginx se non proxati
            root /var/www/html;
        }
    }
}

5. Abilitare la compressione Gzip

La compressione delle risposte prima di inviarle ai client può ridurre significativamente l'utilizzo della larghezza di banda e migliorare i tempi di caricamento delle pagine, specialmente per i contenuti testuali.

gzip on

Attiva la compressione gzip.

gzip_comp_level

Imposta il livello di compressione (1-9). Il livello 1 è il più veloce con meno compressione; il livello 9 è il più lento con la massima compressione. Il livello 6 offre solitamente un buon equilibrio.

gzip_types

Specifica i tipi MIME che devono essere compressi. Includere i tipi comuni di testo, CSS, JavaScript e JSON.

gzip_min_length

Imposta la lunghezza minima di una risposta (in byte) per la quale la compressione dovrebbe essere abilitata. I file piccoli non traggono molto beneficio e potrebbero persino essere più lenti a causa dell'overhead di compressione.

gzip_proxied

Istruisce Nginx a comprimere le risposte anche se sono proxate. any è un valore comune.

gzip_vary

Aggiunge l'intestazione Vary: Accept-Encoding alle risposte, informando i proxy che la risposta potrebbe differire in base all'intestazione Accept-Encoding della richiesta.

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6; # Livello di compressione 1-9 (6 è un buon equilibrio)
    gzip_buffers 16 8k; # 16 buffer, ciascuno da 8KB
    gzip_http_version 1.1; # Versione HTTP minima per la compressione
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
    gzip_min_length 1000; # Comprimi solo risposte più grandi di 1KB
}

6. Ottimizzare il logging

Sebbene i log siano essenziali per il monitoraggio e la risoluzione dei problemi, un logging eccessivo o non ottimizzato può introdurre un significativo I/O su disco, specialmente su siti ad alto traffico.

access_log

• Disabilitare per risorse statiche: Per contenuti statici molto acceduti (immagini, CSS, JS), disabilitare access_log può risparmiare molta I/O.
• Buffering: Nginx può bufferizzare le voci di log in memoria prima di scriverle su disco, riducendo la frequenza delle scritture su disco. I parametri buffer e flush sono usati qui.

error_log

Impostare il livello di logging appropriato (crit, error, warn, info, debug). Per la produzione, warn o error sono solitamente sufficienti per catturare problemi critici senza inondare i log.

http {
    server {
        # Log di accesso predefinito per i contenuti dinamici
        access_log /var/log/nginx/access.log main;

        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            access_log off; # Disabilita il logging per i file statici comuni
            expires 30d;
        }
    }

    # Esempio di log di accesso bufferizzato per il contesto HTTP principale
    # access_log /var/log/nginx/access.log main buffer=16k flush=5s;
    error_log /var/log/nginx/error.log warn; # Logga solo avvisi e superiori
}

7. Regolare i timeout

I timeout configurati in modo appropriato impediscono a Nginx di mantenere le connessioni inattive troppo a lungo, liberando risorse.

Timeout lato client

• client_body_timeout: Per quanto tempo Nginx attende che un client invii il corpo della richiesta.
• client_header_timeout: Per quanto tempo Nginx attende che un client invii l'intestazione della richiesta.
• send_timeout: Per quanto tempo Nginx attende che un client accetti la risposta dopo che è stata inviata.

Timeout proxy/FastCGI (se applicabile)

• proxy_connect_timeout: Timeout per stabilire una connessione con un server proxato.
• proxy_send_timeout: Timeout per trasmettere una richiesta al server proxato.
• proxy_read_timeout: Timeout per leggere una risposta dal server proxato.

http {
    client_body_timeout 15s; # Il client ha 15 secondi per inviare il corpo
    client_header_timeout 15s; # Il client ha 15 secondi per inviare le intestazioni
    send_timeout 15s; # Nginx ha 15 secondi per inviare la risposta al client

    # Per scenari proxy
    proxy_connect_timeout 5s; # 5 secondi per connettersi all'upstream
    proxy_send_timeout 15s; # 15 secondi per inviare la richiesta all'upstream
    proxy_read_timeout 15s; # 15 secondi per leggere la risposta dall'upstream

    # Per scenari FastCGI
    fastcgi_connect_timeout 5s;
    fastcgi_send_timeout 15s;
    fastcgi_read_timeout 15s;
}

8. Ottimizzazione SSL/TLS

Per i siti abilitati HTTPS, l'ottimizzazione delle impostazioni SSL/TLS è cruciale per ridurre il sovraccarico della CPU e migliorare le prestazioni dell'handshake.

ssl_session_cache e ssl_session_timeout

Abilita il caching delle sessioni SSL per evitare l'handshake TLS completo computazionalmente costoso per le connessioni successive dallo stesso client.

ssl_protocols e ssl_ciphers

Utilizzare protocolli TLS moderni e robusti (come TLSv1.2 e TLSv1.3) e suite di cifratura sicure. Dare priorità ai cifrari del server con ssl_prefer_server_ciphers on.

ssl_stapling

Abilita l'OCSP stapling, dove Nginx recupera periodicamente la risposta OCSP dalla CA e la "applica" all'handshake SSL/TLS. Questo riduce la latenza lato client evitando una query OCSP separata.

server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;

    ssl_session_cache shared:SSL:10m; # Cache condivisa per 10MB di dati di sessione
    ssl_session_timeout 10m; # Le sessioni scadono dopo 10 minuti

    ssl_protocols TLSv1.2 TLSv1.3; # Usa protocolli moderni e sicuri
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s; # Specificare i resolver DNS per le query OCSP
    resolver_timeout 5s;
}

9. Cache dei file aperti

Nginx può memorizzare nella cache i descrittori di file per i file a cui si accede frequentemente, riducendo la necessità di chiamate di sistema ripetute per aprire e chiudere i file.

open_file_cache

Abilita la cache, specificando il numero massimo di elementi e per quanto tempo gli elementi inattivi rimangono.

open_file_cache_valid

Imposta la frequenza con cui la cache dovrebbe controllare la validità dei suoi elementi.

open_file_cache_min_uses

Specifica il numero minimo di volte in cui un file deve essere acceduto entro il tempo inactive per rimanere nella cache.

open_file_cache_errors

Determina se Nginx dovrebbe memorizzare gli errori quando apre i file.

http {
    open_file_cache max=100000 inactive=60s; # Cache fino a 100.000 descrittori di file per 60s
    open_file_cache_valid 80s; # Controlla la validità ogni 80 secondi
    open_file_cache_min_uses 1; # Cache i file usati almeno una volta
    open_file_cache_errors on; # Cache gli errori relativi all'apertura dei file
}

Conclusione

La messa a punto delle prestazioni di Nginx è un processo continuo, non una configurazione una tantum. Questa lista di controllo fornisce un robusto punto di partenza per ottimizzare i vostri siti web ad alto traffico. Ricordate che la configurazione "perfetta" dipende fortemente dalla vostra specifica applicazione, dai modelli di traffico e dalle risorse del server. Testate sempre le modifiche in un ambiente di staging prima di implementarle in produzione e monitorate continuamente le vostre istanze Nginx e i server backend utilizzando strumenti come il monitoraggio dell'attività live di Nginx Plus, Prometheus, Grafana o strumenti di sistema di base (ad esempio, top, iostat, netstat).

Applicando meticolosamente queste ottimizzazioni e adattandole al vostro ambiente, potete assicurarvi che Nginx consegni i contenuti con velocità, efficienza e affidabilità eccezionali, anche sotto i carichi più impegnativi.