Una cache di oggetti tiene in memoria il RISULTATO del lavoro perché la richiesta successiva non lo ripeta. Su un sito che pone al database le stesse domande a ogni pagina l'effetto è grande. Su un sito le cui pagine sono lente per altri motivi è nullo.

Quando aiuta

  • Un CMS che carica decine di righe di impostazioni a ogni richiesta: WordPress chiede le sue opzioni su ogni singola pagina.
  • Menù, tassonomie, metadati utente: piccoli, ripetuti, identici.
  • Le sessioni, che altrimenti diventano migliaia di piccoli file su disco.

Quando non aiuta

Una pagina lenta per UNA query su una tabella grande resta esattamente altrettanto lenta. La cache risparmia lavoro ripetuto, non lavoro costoso. Prima sistemi la query; metterla in cache nasconde soltanto quanto sia grave, finché la cache non si raffredda.

Metta un limite di memoria e una politica di sfratto

maxmemory 256mb
maxmemory-policy allkeys-lru

Senza maxmemory Redis cresce finché alla macchina non resta memoria, e allora il kernel uccide qualcosa: spesso il database. allkeys-lru butta via invece la chiave usata da più tempo, che è ciò che una cache dovrebbe fare.

Lo leghi a localhost

Redis non ha autenticazione per impostazione predefinita. Un Redis raggiungibile da internet è una porta aperta: gli si può ordinare di scrivere file. Lo leghi a 127.0.0.1 e pretenda una password.
bind 127.0.0.1
requirepass a-long-random-string

Controlli che venga davvero usata

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

Colpi molto superiori ai mancati significa che funziona. Se prevalgono i mancati, le chiavi scadono troppo in fretta oppure qualcosa svuota la cache a ogni richiesta.

Una cache di pagina e una cache di oggetti sono cose diverse. La cache di pagina serve una pagina intera già finita e aiuta i visitatori anonimi; la cache di oggetti aiuta quelli autenticati, le cui pagine non si possono condividere.