Caching di Base con Nginx: Migliora i Tempi di Risposta

Il caching di base con Nginx può migliorare i tempi di risposta salvando una copia delle risposte upstream e servendole di nuovo senza interrogare l'applicazione ogni volta. Se usato con attenzione, il caching riduce il carico del backend, attenua i picchi di traffico e rende le richieste ripetute più veloci.

Il caching non è solo per siti di grandi dimensioni. Anche una piccola applicazione può trarre vantaggio quando pagine, risposte API o file statici vengono richiesti spesso e non cambiano ogni secondo.

Cosa Può Mettere in Cache Nginx

Nginx può mettere in cache le risposte da un server upstream quando agisce come proxy inverso. Questo è diverso dal normale caching del browser. Il caching del browser memorizza i file sul dispositivo dell'utente. Il caching proxy di Nginx memorizza le risposte sul server in modo che molti utenti possano beneficiare della stessa copia cache.

Una configurazione semplice di proxy cache ha due parti. Prima, definisci una zona cache nel blocco http:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
    max_size=1g inactive=60m use_temp_path=off;

Poi abilita quella cache in un blocco server o location:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_valid 404 1m;
    add_header X-Cache-Status $upstream_cache_status;
}

La direttiva proxy_cache_path crea l'area di archiviazione della cache. keys_zone definisce la memoria condivisa per le chiavi cache e i metadati. max_size limita l'uso del disco. inactive rimuove gli elementi che non sono stati accessati per un po'.

Le direttive proxy_cache_valid decidono per quanto tempo certi codici di risposta rimangono in cache. Nell'esempio, le risposte di successo vengono memorizzate per 10 minuti, mentre le risposte 404 per 1 minuto.

L'header X-Cache-Status è utile durante i test. Può mostrare valori come MISS, HIT, BYPASS o EXPIRED, a seconda di ciò che è successo.

Per i siti che usano anche Nginx come proxy inverso, questo si abbina naturalmente con la configurazione del proxy inverso.

Decidere Cosa Dovrebbe Essere Memorizzato in Cache

La parte più difficile del caching con Nginx non è scrivere le direttive. È decidere quale contenuto è sicuro riutilizzare.

Buoni candidati per il caching includono:

• Pagine di marketing pubbliche.
• Pagine di documentazione pubbliche.
• Pagine di elenchi prodotti che si aggiornano secondo un programma prevedibile.
• Risposte API anonime.
• Risposte upstream costose che sono identiche per molti utenti.

Cattivi candidati per il caching includono:

• Pagine dell'account.
• Carrelli della spesa.
• Schermate di amministrazione.
• Risposte che includono dati utente privati.
• Pagine che cambiano in base a cookie o header di autorizzazione.

Se una risposta è diversa per ogni utente, non metterla in cache a meno che tu non abbia una strategia di chiave cache molto chiara. Servire accidentalmente la risposta privata di un utente a un altro utente è un bug grave.

Puoi bypassare il caching quando le richieste includono dati di sessione o autorizzazione:

proxy_cache_bypass $http_authorization;
proxy_no_cache $http_authorization;

Per sessioni basate su cookie, puoi usare un modello simile:

proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;

Il nome esatto del cookie dipende dalla tua applicazione. Non copiare questo ciecamente senza verificare come la tua app gestisce le sessioni.

Uno scenario pratico: la homepage pubblica del tuo blog è generata da un'applicazione e richiede 300 millisecondi in un giorno di traffico intenso. Se memorizzi in cache quella pagina per 5 minuti, la maggior parte dei visitatori riceve la copia cache rapidamente, e l'app la rigenera solo occasionalmente. Questo è un caso d'uso valido perché la homepage è pubblica e non specifica per utente.

Chiavi Cache, Header e Pulizia

Nginx usa una chiave cache per decidere se due richieste dovrebbero condividere la stessa risposta cache. La chiave cache predefinita è solitamente basata su schema, metodo, host e URI. Per molti siti, questo è sufficiente.

Se le stringhe di query cambiano la risposta, assicurati che facciano parte della chiave. Se le stringhe di query sono solo parametri di tracciamento, potresti volerle normalizzare a livello di applicazione o CDN invece di lasciare che ogni utm_source crei una voce cache separata.

Anche gli header cache upstream contano. La tua app può inviare header come:

Cache-Control: public, max-age=600

o:

Cache-Control: private, no-store

Nginx può essere configurato per rispettare o sovrascrivere questi header, ma dovresti scegliere una politica chiara. Se gli sviluppatori dell'app si aspettano che Cache-Control: no-store impedisca il caching, sovrascrivere quel comportamento in Nginx può creare risultati confusi e rischiosi.

La pulizia è un'altra questione operativa. Nginx open source non include un semplice endpoint di pulizia cache integrato come alcuni moduli commerciali o di terze parti. Molti team gestiscono questo utilizzando durate cache brevi, URL con versione o script di deployment che puliscono la directory della cache durante rilasci controllati.

TTL brevi sono spesso sufficienti. Una cache di 60 secondi su un endpoint trafficato può comunque rimuovere una grande quantità di traffico backend mantenendo il contenuto ragionevolmente fresco.

Testare il Comportamento della Cache

Dopo aver abilitato il caching, richiedi lo stesso URL più volte e ispeziona gli header della risposta:

curl -I https://example.com/

Se hai aggiunto X-Cache-Status, la prima richiesta potrebbe mostrare MISS, e le richieste successive dovrebbero mostrare HIT. Se ogni richiesta è un MISS, controlla gli header della risposta, le regole di bypass cache, i cookie della richiesta e se la directory della cache è scrivibile dal processo worker di Nginx.

Testa anche il comportamento con utente loggato e non loggato. È qui che emergono molti errori di caching. Apri una finestra del browser in incognito, accedi come utente di test e conferma che le pagine private non siano memorizzate in cache pubblicamente.

Monitora anche l'uso del disco. Una cache senza limiti pratici può riempire un filesystem. Usa max_size, mantieni lo storage della cache separato dalle partizioni critiche del sistema quando possibile e attiva avvisi sulla pressione del disco.

Quando Chiedere Aiuto

Coinvolgi un ingegnere Nginx o di piattaforma esperto se il contenuto cache appare sotto l'utente sbagliato, se il tuo tasso di hit cache rimane basso dopo la messa a punto o se i file cache riempiono il disco inaspettatamente. I problemi di caching possono sembrare semplici mentre nascondono comportamenti specifici dell'applicazione.

Dovresti anche chiedere aiuto prima di mettere in cache API autenticate, dashboard multi-tenant o flussi relativi ai pagamenti. Quelle aree necessitano di una progettazione attenta.

Il caching di base con Nginx funziona meglio quando inizi con risposte pubbliche e ripetibili e durate cache brevi. Aggiungi header visibili dello stato della cache durante i test, rispetta i confini dei contenuti privati e misura sia il tempo di risposta che il carico del backend. Fatto bene, il caching offre pagine più veloci agli utenti mentre dà alla tua applicazione spazio per respirare.