← Torna agli articoli
Performance e database

Il caching è più di solo Redis e query al database. Una mappa completa delle prestazioni.

Una mappa completa dei livelli di caching nelle applicazioni moderne: cache del browser, caching completo delle pagine, caching dell'opcode, caching dei frammenti, Redis, cache delle query MySQL e tabelle aggregate.

Il caching è più di solo Redis e query al database. Una mappa completa delle prestazioni.
Articolo in evidenza ↗

Il caching è più di solo Redis e query al database. Una mappa completa delle prestazioni.

Oggi mi sono imbattuto in un'analisi approfondita sui tipi di caching, e questo mi ha ispirato a strutturare le mie conoscenze. Spesso pensiamo al caching come a Redis o a una cache di query del database. Ma in realtà è un intero ecosistema che opera a ogni livello di un'applicazione!

Quindi, cos'è una cache? In parole semplici, una cache è un buffer intermedio ad accesso rapido dove vengono memorizzati i dati. La sua missione principale è consentire di lavorare con grandi volumi di dati nel minor tempo possibile, utilizzando risorse limitate, che si tratti della potenza del server o della larghezza di banda dell'utente.

Analizziamo dove vivono questi "acceleratori".

🖥️ 1. Caching lato client (cache del browser)

Qui risparmiamo traffico e latenza tra l'utente e il server. Al browser viene indicato di usare una copia locale, e il server risponde con lo stato 304 Not Modified.

  • Caching di file e immagini: Perfetto per siti ricchi di media. Header come Expires e Cache-Control indicano al browser di memorizzare le risorse per settimane. Il problema: se un file cambia, l'utente potrebbe non vedere l'aggiornamento immediatamente.
  • Caching HTTPS: Gli header di sicurezza (ad esempio, Strict-Transport-Security) costringono il browser a usare sempre HTTPS per il tuo dominio.
  • Caching della Certificate Authority (CA): Memorizza il "timbro" di fiducia del tuo certificato SSL, così il browser non deve validarlo con la CA a ogni visita.
  • Caching delle pagine: Il tipo più intelligente. Usando header come ETag e Last-Modified, il server verifica se una pagina è cambiata dall'ultima visita dell'utente. Se no, invia un 304, e il browser carica la copia locale.

In sintesi: Il caching del browser risparmia traffico e accelera le visite di ritorno, ma per attivarlo, un utente deve prima visitare il sito. Quindi, sebbene aiuti, non riduce drasticamente il carico iniziale del server.

🚀 2. Caching lato server

Qui i dati sono memorizzati sul server e funzionano secondo un principio "uno-a-molti". Questa è la nostra artiglieria principale nella battaglia per le prestazioni.

  • 2.1. Caching completo delle pagine: Il metodo più efficace. Una pagina HTML completamente renderizzata viene servita istantaneamente dalla memoria, consentendo anche a un server modesto di gestire milioni di richieste. Ideale per utenti ospiti dove il contenuto non è personalizzato. Lo svantaggio: non adatto a pagine specifiche per l'utente. Spesso usato con un TTL (ad esempio, da 2 minuti).
  • 2.2. Caching dell'opcode PHP: (OPcache, APC). Memorizza il bytecode compilato dello script, così non deve essere compilato a ogni richiesta. Riduce crucialmente il carico della CPU.
  • 2.3. Caching parziale (frammento): Lo strumento più complesso ma potente. Consente di memorizzare nella cache parti dinamiche di una pagina (ad esempio, una barra laterale, un elenco di prodotti) con dipendenze da tabelle del database, sessioni utente o parametri GET. Il vantaggio principale: ridurre drasticamente le query al database per gli utenti autenticati. Scalare un pool di server applicativi è più facile che scalare un cluster di database.
  • 2.4 / 2.5. Caching dei dati in memoria (Redis, Memcached): Qui vivono i dati serializzati: risultati di calcoli pesanti, file di configurazione, stato del sistema. Questo è il nostro strumento principale per memorizzare nella cache i dati dell'applicazione, non solo l'HTML renderizzato.
  • 2.6. Cache delle query MySQL: Un classico, ma con riserve. Le query che usano funzioni come UNIX_TIMESTAMP() invalidano costantemente la cache. La soluzione è usare condizioni che cambiano meno frequentemente per consentire alle query adiacenti di essere memorizzate nella cache.
  • 2.7. Caching tramite viste aggregate/materializzate: La regola d'oro: "Le letture dovrebbero superare significativamente le scritture." Se i dati cambiano raramente ma vengono letti spesso, pre-calcolali e memorizzali in una tabella di riepilogo.

🗺️ Riepilogo: è tutta una questione di strategia

Un caching efficace non è un singolo proiettile d'argento; è una difesa a più livelli. Una strategia ben costruita assomiglia a un insieme di bambole russe: CDN -> Web Server (cache completa delle pagine) -> Backend (cache dei frammenti) -> Cache in memoria (Redis) -> Cache del database -> Tabelle aggregate.

Capire quale strumento usare a quale livello è la vera arte di costruire sistemi veloci e reattivi.

Tecnologie e argomenti

Tag dell'articolo

Nessun articolo corrisponde a questi filtri.

Hai un progetto o un'idea da discutere?

Parliamone ↗