Object cache: cos’è e come funziona

Object cache in sintesi

• Cosa memorizza: singoli dati dinamici (opzioni, post, metadati) e non l’intera pagina HTML.
• Differenza dalla page cache: la page cache salva l’output statico completo, l’object cache salva i dati grezzi che lo compongono.
• Due modalità: non persistente (dura una sola richiesta) o persistente tramite un backend esterno come Redis o Memcached.
• Dove serve di più: siti dinamici con molte query ripetute, come cataloghi e-commerce o aree riservate.
• Tecnologie principali: Redis, Memcached e, in misura minore, Apcu o SQLite come alternative locali.

Cos’è l’object cache e in cosa differisce dalla cache di pagina

Un’applicazione web dinamica esegue decine di interrogazioni al DB a ogni caricamento: recupera il contenuto, le impostazioni, i permessi utente. L’object cache intercetta questo lavoro ripetitivo salvando il singolo risultato — non l’intera pagina — in una struttura chiave-valore conservata in memoria. Quando lo stesso dato viene richiesto di nuovo, il sistema lo restituisce dalla memoria invece di interrogare nuovamente il database.

Questa logica distingue l’object cache da altre forme di caching che coesistono nello stesso ambiente. La page cache produce una copia statica dell’HTML finale e di norma viene servita solo agli utenti non autenticati, perché una copia unica non può adattarsi a contenuti personalizzati come un carrello o una dashboard. L’object cache, al contrario, continua a funzionare anche per sessioni autenticate, poiché non salva l’intera risposta ma i frammenti di dato che la compongono. Esiste anche una terza categoria, la cache del browser, che conserva asset statici (immagini, fogli di stile, script) direttamente sul dispositivo dell’utente: opera a un livello diverso, lato client, e non interagisce con il database.

In un contesto PHP, l’object cache si applica tipicamente a operazioni computazionalmente costose: query complesse, calcoli ripetuti, trasformazioni di dati. Il principio resta identico indipendentemente dal framework: memorizzare un valore sotto una chiave univoca ed evitare di rigenerarlo finché resta valido.

Come funziona l’object cache passo per passo

Il meccanismo si basa su un sistema chiave-valore che verifica, prima di ogni operazione costosa, se il risultato richiesto è già disponibile in memoria.

1. L’applicazione richiede un dato, ad esempio il risultato di una query complessa.
2. Il sistema controlla se esiste già una voce corrispondente nella cache: se la trova, si parla di cache hit e il dato viene restituito immediatamente dalla memoria.
3. Se la voce non esiste (cache miss), l’applicazione interroga il database o esegue il calcolo originale.
4. Il risultato ottenuto viene salvato in memoria sotto una chiave univoca, insieme a un eventuale TTL che ne definisce la validità temporale.
5. Alla richiesta successiva identica, il sistema trova il dato già pronto e salta il passaggio al database.

Questo scambio continuo tra hit e miss determina l’efficacia della cache: più alta è la percentuale di hit, maggiore è il carico sottratto al database. Il principio vale anche su scala più ampia: lo studio Small Cache, Big Effect (2011) mostra che, nei servizi distribuiti su più nodi, una cache front-end di piccole dimensioni dedicata agli elementi più richiesti basta a riequilibrare il carico tra i server. Lo stesso studio ricorda che, secondo gli autori di Amazon Dynamo, il 10% dei nodi sostiene quasi sempre un carico superiore di almeno il 15% alla media.

Object cache non persistente e persistente: le differenze

Non tutte le implementazioni di object cache conservano i dati nello stesso modo: la distinzione principale riguarda la durata di vita della memoria utilizzata.

La cache non persistente esiste già per impostazione predefinita in molti framework applicativi: svolge un compito utile ma limitato, perché evita solo le duplicazioni interne a un singolo caricamento. La versione persistente richiede invece un livello di memoria esterno, condiviso tra tutte le richieste in arrivo, ed è quella che produce un reale calo del traffico verso il database nel tempo.

L’object cache in WordPress: la classe nativa

WordPress include fin dalla sua architettura di base una classe dedicata, WP_Object_Cache, che intercetta automaticamente funzioni comuni come il recupero di opzioni o di metadati legati a un contenuto, inclusi quelli impostati tramite un custom field. Ogni volta che il codice richiede uno di questi valori, la classe verifica prima la propria memoria interna prima di interrogare il database.

Il limite di questa implementazione nativa è la durata: per impostazione predefinita resta attiva solo per il tempo necessario a generare la singola pagina richiesta, dopodiché la memoria viene svuotata. Questo comportamento spiega perché, anche su siti con un sistema di cache già configurato, il beckend (pannello di amministrazione wordpress)  risulti spesso più lenta della parte frontend: le schermate di gestione eseguono numerose query a ogni caricamento e non beneficiano di una memorizzazione che sopravviva tra una richiesta e l’altra.

Redis, Memcached e le altre tecnologie per la cache persistente

Per rendere permanente l’object cache serve un servizio di memorizzazione separato dal linguaggio applicativo, accessibile tramite una logica simile a un’interfaccia di programmazione che scambia comandi di lettura e scrittura su chiavi.

Redis

Archivio dati in memoria che supporta strutture complesse come liste, hash e code; può opzionalmente scrivere una copia su disco per non perdere i dati a un riavvio.

Memcached

Sistema di caching distribuito pensato per semplicità e velocità, senza le strutture dati avanzate offerte da Redis.

Apcu

Estensione PHP che conserva dati in memoria condivisa a livello di singolo server, utile quando non è disponibile un servizio esterno dedicato.

SQLite

Motore di database leggero talvolta impiegato come backend di cache su disco quando mancano sia memoria dedicata sia un servizio Redis o Memcached.

La scelta tra Redis e Memcached dipende dal tipo di dato da conservare: Redis è preferibile quando l’applicazione deve gestire strutture articolate o necessita di persistenza su disco, mentre Memcached resta adatto a scenari in cui serve solo memorizzare coppie chiave-valore semplici, con un design volutamente essenziale. L’integrazione in un ambiente come WordPress avviene tramite un file drop-in che sostituisce la classe di cache predefinita, spesso gestito da un plugin o da una soluzione dedicata come Object Cache Pro, pensata per combinare più comandi Redis in un’unica operazione e ridurre ulteriormente i tempi di risposta.

Come si attiva una cache persistente

Con Redis o Memcached l’attivazione richiede un intervento a livello di server: installare un plugin non basta se il servizio non è disponibile.

1. Verificare che il server o il piano di hosting metta a disposizione Redis o Memcached come servizio attivo, poiché nessun plugin può installare questo livello software se l’infrastruttura non lo supporta.
2. Collegare l’applicazione al servizio tramite un file drop-in (ad esempio object-cache.php) che sostituisce la gestione della cache predefinita con quella del backend esterno.
3. Configurare i parametri di connessione (host, porta, eventuale autenticazione) e verificare, tramite gli strumenti diagnostici del CMS, che la cache risulti effettivamente persistente e non più legata alla singola richiesta.

Se l’ambiente di hosting non fornisce Redis o Memcached, restano due alternative che non richiedono un servizio esterno: APCu, quando l’estensione è abilitata nella configurazione PHP, oppure un drop-in basato su SQLite, che salva la cache in un file su disco. In mancanza anche di queste, resta attiva la sola cache non persistente nativa.

Quali vantaggi produce l’object cache

Il primo è la velocità dell’area amministrativa dei CMS, che esegue numerose operazioni di lettura a ogni schermata e trae vantaggio immediato da una cache che sopravvive tra una richiesta e l’altra.

Oltre alla riduzione del carico, emergono tre effetti collegati. Il primo è la velocità dell’area amministrativa dei CMS, che esegue centinaia di operazioni di lettura a ogni schermata e trae vantaggio immediato da una cache che sopravvive tra una richiesta e l’altra. Il secondo è il TTFB più basso, perché il server impiega meno tempo a comporre la risposta quando non deve interrogare ripetutamente il database. Il terzo è la capacità di assorbire picchi di traffico improvvisi — campagne promozionali, lanci di prodotto — senza che il database diventi il collo di bottiglia che fa cadere l’intero servizio, uno scenario con conseguenze simili, sul piano della saturazione delle risorse, a quelle descritte per un attacco DDoS, pur avendo origine da traffico legittimo.

Questi vantaggi si manifestano in proporzione alla quantità di query ripetute che l’applicazione genera: un catalogo con filtri, varianti prodotto e carrelli attivi produce molte più occasioni di hit rispetto a un sito prevalentemente statico.

Quando conviene attivarla e quando no

La decisione dipende dalla quantità di dati gestiti, dal profilo di traffico e dalla complessità delle query, non da una regola valida per ogni sito. WordPress offre un riferimento concreto: il controllo Site Health suggerisce una cache persistente quando il database supera determinate soglie, ad esempio 1.000 post, 1.000 utenti o 1.000 commenti.

Se il sito è dinamico e ad alto traffico: attiva una cache persistente

Negozi online con cataloghi estesi, piattaforme con utenti autenticati, aree riservate con contenuti personalizzati: in questi casi la cache persistente riduce in modo misurabile il tempo di risposta e la pressione sul database durante i picchi.

Se il sito è prevalentemente statico: valuta prima altre ottimizzazioni

Un blog a basso traffico già coperto da una page cache efficace trae un beneficio marginale dall’object cache persistente, perché il numero di query ripetute per visitatore resta contenuto. In questi casi è più utile verificare se il rallentamento dipende da codice non ottimizzato, immagini pesanti o chiamate a servizi esterni, cause che l’object cache non risolve.

Una condizione intermedia riguarda i siti con bottleneck altrove: se il tempo di risposta resta alto anche dopo l’attivazione della cache, il problema probabile non è il database ma la logica applicativa o le risorse esterne richiamate a ogni pagina.

Errori comuni e limiti dell’object cache

Alcune idee diffuse sull’object cache e sulle tecnologie che la rendono persistente portano a configurazioni poco efficaci o a aspettative sbagliate.

Un primo equivoco frequente riguarda Redis: non è un database relazionale, ma un archivio in memoria ottimizzato per la velocità. La durata dei dati dipende da come viene configurata la persistenza: senza scrittura su disco tutto si perde a un riavvio, con i soli snapshot periodici si perdono le modifiche successive all’ultimo salvataggio, mentre il registro di ogni operazione di scrittura (AOF) riduce al minimo la perdita. Quando Redis è usato come object cache, i dati canonici (informazioni utente, cataloghi completi) devono comunque restare nel database principale: la cache ne conserva solo una copia rigenerabile. Un secondo equivoco riguarda il rapporto con i plugin di ottimizzazione: Redis gestisce la cache degli oggetti ma non sostituisce un sistema di cache di pagina, compressione o integrazione con una rete di distribuzione dei contenuti, funzioni che restano affidate a strumenti distinti.

Esiste infine un rischio legato ai dati non aggiornati: una cache persistente può restituire un valore non più corrispondente allo stato reale del database se l’invalidazione non avviene correttamente alla modifica dei contenuti. La mitigazione standard combina un tempo di validità (TTL) con meccanismi automatici di invalidazione che cancellano la voce in cache non appena il dato sottostante cambia.

Domande frequenti sull’object cache

Cos’è l’object cache?

È un sistema che conserva in memoria singoli dati generati da un’applicazione, come risultati di query al database, per evitare di ricalcolarli a ogni richiesta e ridurre i tempi di risposta complessivi.

Che differenza c’è tra object cache e page cache?

La page cache salva l’intero HTML statico di una pagina e di norma viene servita solo agli utenti non autenticati; l’object cache salva i singoli dati dinamici e continua a funzionare anche per contenuti personalizzati o sessioni attive.

Cosa cambia tra cache persistente e non persistente?

La cache non persistente dura solo per la richiesta in corso e viene svuotata subito dopo; quella persistente, affidata a un backend esterno come Redis o Memcached, conserva i dati tra richieste e sessioni diverse.

Come si attiva una cache persistente?

Serve un servizio Redis o Memcached disponibile sul server, collegato tramite un file drop-in che sostituisce la gestione di cache predefinita e configurato con i parametri di connessione corretti.

Redis è un database o una cache?

Redis è un archivio dati in memoria, non un database relazionale. Può conservare i dati su disco tramite snapshot o registro delle scritture, ma la loro durata dipende da come è configurata la persistenza; usato come object cache contiene solo copie rigenerabili dei dati del database principale.

Quando è meglio evitare l’object cache persistente?

Su siti statici o a basso traffico già coperti da una page cache efficace il beneficio è marginale; in questi casi conviene prima verificare codice, immagini e chiamate esterne come possibili cause reali di lentezza.

Quali sono i rischi principali dell’object cache?

Il rischio maggiore è servire dati non aggiornati se l’invalidazione non funziona correttamente; si mitiga con un tempo di validità (TTL) e meccanismi automatici che aggiornano la cache ai cambiamenti del dato.

Meglio Redis o Memcached per la cache persistente?

Redis conviene con strutture dati complesse o quando serve persistenza su disco; Memcached resta adatto quando bastano semplici coppie chiave-valore e si preferisce un sistema dal design essenziale.