Ottimizzazione delle Prestazioni di Nginx: Consigli per Siti Web più Veloci

I siti lenti di solito derivano da una manciata di cause: risposte upstream costose, header cache mancanti, asset sovradimensionati, worker bloccati o un server ottimizzato per impostazioni predefinite invece che per il tuo traffico. L'ottimizzazione delle prestazioni di Nginx funziona meglio quando misuri prima, modifichi un'impostazione alla volta e mantieni la configurazione leggibile.

Usa gli esempi seguenti come punti di partenza, poi testali sotto carico con la tua applicazione. Un server di file statici, un sito WordPress/PHP-FPM e un proxy inverso API richiedono compromessi diversi.

Comprendere i Colli di Bottiglia delle Prestazioni di Nginx

Inizia individuando il collo di bottiglia. Le cause comuni includono:

• Utilizzo della CPU: Un carico elevato della CPU rallenta la gestione delle richieste, la compressione e il lavoro TLS.
• Pressione della memoria: Lo swapping danneggia gravemente la latenza.
• I/O di rete: Collegamenti lenti, finestre upstream piccole o perdita di pacchetti possono dominare il tempo di risposta.
• I/O del disco: I file statici, i file cache e i log toccano ancora l'archiviazione.
• Latenza upstream: Nginx può essere veloce mentre il tuo server applicativo è lento.

Strumenti come top, htop, iostat, ss, i log di accesso e il modulo stub_status di Nginx possono aiutarti a decidere cosa ottimizzare.

Tecniche Fondamentali di Ottimizzazione di Nginx

Processi Worker e Connessioni

La direttiva worker_processes controlla quanti processi worker Nginx avvia. auto è un'impostazione predefinita pratica perché Nginx rileva i core CPU disponibili.

# Imposta worker_processes al numero di core CPU
worker_processes auto;

All'interno di ogni processo worker, worker_connections limita quante connessioni simultanee quel worker può aprire. Il limite superiore approssimativo è worker_processes * worker_connections, ma la capacità reale dipende anche dalle connessioni upstream, dai limiti dei file aperti, dal comportamento keep-alive e dai limiti del sistema operativo.

# Aumenta worker_connections per siti ad alto traffico
worker_connections 1024;

Se vedi Too many open files, aumentare solo worker_connections non è sufficiente. Controlla anche il limite dei descrittori di file del servizio, spesso controllato da LimitNOFILE di systemd o dai limiti della shell.

Strategie di Caching

Il caching è solitamente l'ottimizzazione delle prestazioni di Nginx di maggior impatto perché previene il lavoro ripetuto.

Caching del Browser

Dì ai browser di memorizzare nella cache gli asset statici con versione come immagini, CSS e JavaScript. Usa durate lunghe solo quando i nomi dei file cambiano al deploy, come app.8f3c1.css.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Caching Proxy

Se Nginx è un proxy inverso, può memorizzare nella cache risposte backend selezionate. Funziona bene per pagine pubbliche, risposte API con chiare regole di freschezza e pagine costose che non variano per utente.

Prima, definisci una zona cache nel blocco http:

http {
    # ... altre configurazioni http ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
    # ...
}

• /var/cache/nginx: La directory in cui verranno archiviati i file cache.
• levels=1:2: Definisce la struttura delle directory per la cache.
• keys_zone=my_cache:10m: Crea una zona di memoria condivisa denominata my_cache con una dimensione di 10 MB per memorizzare le chiavi cache.
• max_size=1g: Imposta la dimensione massima della cache.
• inactive=60m: Rimuove le voci cache a cui non si è avuto accesso per 60 minuti.

Quindi, abilita il caching nel tuo blocco location:

location / {
    proxy_pass http://your_backend_app;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m; # Memorizza nella cache le risposte 200 e 302 per 10 minuti
    proxy_cache_valid 404 1m;     # Memorizza nella cache le risposte 404 per 1 minuto
    add_header X-Cache-Status $upstream_cache_status;
}

add_header X-Cache-Status $upstream_cache_status; è utile per il debug, mostrando se una richiesta è stata un hit, un miss o un bypass della cache.

Non memorizzare nella cache pagine personalizzate a meno che la tua chiave cache non tenga conto dei dati che modificano la risposta. Ad esempio, una dashboard con accesso effettuato dovrebbe di solito bypassare la cache proxy, mentre /assets/logo.png può essere memorizzato nella cache per molto tempo.

Compressione

La compressione riduce la dimensione del trasferimento per le risposte basate su testo come HTML, CSS, JavaScript, JSON e XML. Non aiuta molto per file già compressi come JPEG, PNG, MP4 o molti formati di archivio.

http {
    # ...
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

• gzip on;: Abilita la compressione Gzip.
• gzip_vary on;: Aggiunge l'header Vary: Accept-Encoding, importante per i proxy cache.
• gzip_proxied any;: Comprime anche le risposte per le richieste proxy.
• gzip_comp_level 6;: Imposta il livello di compressione (1-9, più alto significa migliore compressione ma più CPU).
• gzip_types ...;: Specifica i tipi MIME da comprimere.

Brotli può comprimere bene gli asset di testo, ma le build standard di Nginx open source non includono tutte il supporto Brotli. Controlla il tuo pacchetto o set di moduli prima di aggiungere direttive Brotli.

Gestione delle Connessioni e Keep-Alive

La direttiva keepalive_timeout controlla per quanto tempo una connessione client inattiva rimane aperta. Riutilizzare una connessione evita handshake TCP e TLS extra, ma le connessioni inattive consumano comunque risorse.

http {
    # ...
    keepalive_timeout 65;
    keepalive_requests 1000;
    # ...
}

• keepalive_timeout 65;: Imposta il timeout keep-alive a 65 secondi.
• keepalive_requests 1000;: Imposta il numero massimo di richieste che possono essere effettuate su una singola connessione keep-alive.

Per le API con molte richieste brevi, keep-alive aiuta. Per un server piccolo con molti client inattivi, un timeout più breve potrebbe essere migliore.

Buffering e Limiti della Dimensione delle Richieste

Nginx utilizza buffer per i corpi delle richieste client e le risposte proxy. Le impostazioni predefinite vanno bene per molti siti, ma le app con molti upload e gli header upstream grandi potrebbero aver bisogno di impostazioni esplicite.

http {
    # ...
    client_body_buffer_size 10K;
    client_max_body_size 8M;
    proxy_buffers 8 16k;
    proxy_buffer_size 16k;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
    # ...
}

• client_body_buffer_size: Dimensione del buffer utilizzato per leggere il corpo della richiesta client.
• client_max_body_size: Dimensione massima consentita del corpo della richiesta client.
• proxy_buffers, proxy_buffer_size: Controllano il buffering quando Nginx agisce come proxy.

Evita di copiare ciecamente le impostazioni del buffer. Se vedi upstream sent too big header, indaga sugli header upstream prima di aumentare proxy_buffer_size. Se gli upload falliscono con 413 Request Entity Too Large, imposta client_max_body_size sulla dimensione effettivamente supportata dalla tua app.

Ottimizzazione TLS

Per i siti HTTPS, le impostazioni TLS influenzano sia la latenza che la sicurezza.

• Ripresa della sessione: Usa una cache di sessione per velocizzare le connessioni ripetute.

  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;
  ssl_session_tickets off;
  

• Versioni TLS: Abilita TLS 1.2 e TLS 1.3 a meno che i tuoi requisiti di compatibilità non dicano diversamente.
• OCSP stapling: Può ridurre i round trip di convalida del certificato quando la tua catena di certificati lo supporta.

  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.8.8 8.8.4.4 valid=300s;
  

Servizio di File Statici

Nginx è molto bravo a servire file statici. Queste direttive sono comuni nel blocco http:

• sendfile: Consente al kernel di copiare i dati del file direttamente al socket sui sistemi supportati.

  sendfile on;
  

• tcp_nopush e tcp_nodelay: Ottimizzano il comportamento di invio dei pacchetti per i carichi di lavoro HTTP comuni.

  tcp_nopush on;
  tcp_nodelay on;
  

Monitoraggio e Test

Dopo ogni modifica, testa e confronta. Gli strumenti utili includono:

• stub_status di Nginx: Connessioni attive, connessioni accettate, connessioni gestite e richieste.
• top/htop: Pressione su CPU e memoria.
• iostat: I/O del disco.
• WebPageTest o PageSpeed Insights: Prestazioni lato browser.
• wrk, ab o hey: Test di carico locale su endpoint controllati.

Conserva una copia della configurazione precedente, esegui sudo nginx -t, ricarica e confronta latenza, tasso di errore, CPU e tempo di risposta upstream. La migliore ottimizzazione delle prestazioni di Nginx è quella che le tue misurazioni possono dimostrare.

Consigli Pratici

Inizia con la misurazione, poi risolvi prima il collo di bottiglia più grande. Per la maggior parte dei siti web, ciò significa impostare limiti worker sensati, aggiungere il caching del browser per gli asset statici, abilitare gzip, memorizzare nella cache le risposte upstream sicure e guardare i log dopo ogni ricarica.