Cache in Moodle: Strategie di Caching per Performance

La cache Moodle è il fattore tecnico che più incide sulle performance percepite dagli utenti della piattaforma. Un'istanza Moodle non ottimizzata può impiegare 3-5 secondi per caricare una pagina corso con 50 utenti simultanei; la stessa istanza, con una caching strategy corretta basata su Redis cache, scende sotto il secondo anche con 500 utenti concorrenti. In questo articolo approfondiamo le strategie di ottimizzazione Moodle legate al caching, con configurazioni pratiche testate su istanze reali in produzione.

Come funziona la cache Moodle: architettura a tre livelli

Il sistema di caching di Moodle, introdotto nella versione 2.4 e significativamente migliorato nelle versioni successive, opera su tre livelli gerarchici che determinano le performance LMS complessive:

Application cache

Memorizza dati che persistono tra le richieste e sono condivisi tra tutti gli utenti: definizioni dei corsi, stringhe di lingua, configurazioni dei plugin, albero di navigazione. Questi dati cambiano raramente ma vengono letti migliaia di volte al giorno. Senza caching, ogni lettura genera una query al database; con caching, il dato viene servito dalla memoria in microsecondi.

Session cache

Contiene dati specifici della sessione utente: preferenze, stato della navigazione, risultati di ricerca temporanei. Ogni utente ha la propria session cache, che viene creata al login e distrutta al logout o alla scadenza della sessione.

Request cache

La più effimera: memorizza dati validi solo per la durata di una singola richiesta HTTP. Utile per evitare query duplicate quando lo stesso dato viene richiesto più volte durante la generazione di una pagina. Non richiede storage esterno — utilizza la memoria PHP del processo.

Di default, Moodle utilizza il filesystem per application e session cache. Questo funziona per istanze piccole (sotto i 100 utenti), ma diventa un collo di bottiglia critico con il crescere del carico, perché le operazioni di I/O su disco sono ordini di grandezza più lente delle operazioni in memoria.

Redis cache: la soluzione standard per performance LMS enterprise

La Redis cache è la soluzione raccomandata dalla documentazione ufficiale di Moodle per istanze di medie e grandi dimensioni. Redis è un database in-memory che opera con latenze inferiori al millisecondo, ideale per il caching di dati a lettura frequente.

Installazione e configurazione di base

Su un server Linux (Ubuntu/Debian), l'installazione è diretta:

• Installare Redis server e l'estensione PHP redis (phpredis)
• Configurare Redis per ascoltare su localhost (127.0.0.1) o su un socket Unix per ridurre ulteriormente la latenza
• Allocare memoria sufficiente: per un'istanza Moodle con 5.000 utenti, riservare almeno 512 MB a Redis (parametro maxmemory); per 20.000 utenti, almeno 2 GB
• Impostare la policy di eviction su allkeys-lru (Least Recently Used) per gestire automaticamente il riempimento della memoria

Configurazione in Moodle

Da Amministrazione sito > Plugin > Caching > Configurazione:

• Aggiungere un'istanza di store Redis specificando server (127.0.0.1:6379 o il percorso del socket Unix), prefisso chiave (utile se Redis è condiviso tra più applicazioni) e serializzatore (igbinary è il 30% più veloce di PHP serialize)
• Mappare la cache di tipo "Application" sullo store Redis creato
• Mappare la cache di tipo "Session" su Redis (in alternativa, Moodle dalla versione 3.9 supporta sessioni native su Redis tramite il parametro $CFG->session_handler_class)
• Lasciare la Request cache sul default (memoria PHP) — non beneficia di storage esterno

Il risultato è immediato: su un benchmark con 200 utenti concorrenti, il tempo medio di risposta passa tipicamente da 2.800 ms (filesystem cache) a 650 ms (Redis cache), con un miglioramento del 77%.

Caching strategy avanzata: oltre la configurazione base

Una caching strategy matura per Moodle va oltre la semplice attivazione di Redis. Ecco le ottimizzazioni avanzate:

Separazione degli store per tipo di cache

Utilizzare istanze Redis separate (o database Redis diversi, da 0 a 15) per application cache e session cache previene che un flush della cache applicativa invalidi le sessioni utente, causando logout inaspettati. La configurazione consigliata:

• Redis DB 0: application cache
• Redis DB 1: session cache
• Redis DB 2: MUC (Moodle Universal Cache) store specifici per plugin ad alto traffico

Cache warming

Dopo un deploy o un aggiornamento di Moodle che invalida la cache, le prime pagine caricate saranno lente perché la cache è fredda. Implementare uno script di cache warming che naviga programmaticamente le pagine principali (homepage, catalogo corsi, dashboard) immediatamente dopo il deploy riduce l'impatto sugli utenti.

Configurazione MUC per cache specifiche

Moodle utilizza il Moodle Universal Cache (MUC) framework con decine di definizioni di cache specifiche. Alcune meritano configurazioni dedicate:

• core/string: le stringhe di lingua occupano molta memoria ma cambiano solo con gli aggiornamenti. Configurare un TTL lungo (24 ore).
• core/coursemodinfo: informazioni sui moduli del corso, lette ad ogni caricamento pagina. Priorità massima in Redis.
• core/groupdata: dati sui gruppi, critici per istanze che usano gruppi estensivamente.

Ottimizzazione Moodle: caching nel contesto della performance globale

La cache Moodle è un pilastro dell'ottimizzazione Moodle, ma non opera in isolamento. Per ottenere performance LMS ottimali, deve essere integrata con altre ottimizzazioni:

• OPcache PHP: memorizza il bytecode PHP compilato, eliminando la ricompilazione ad ogni richiesta. Configurare opcache.memory_consumption=256 e opcache.max_accelerated_files=10000 per un'istanza Moodle standard.
• Database tuning: MySQL/MariaDB con InnoDB buffer pool dimensionato al 70-80% della RAM disponibile, query cache disabilitata (ridondante con Redis), e indici ottimizzati sulle tabelle più query-intensive (mdl_logstore_standard_log, mdl_grade_grades).
• Reverse proxy e CDN: Nginx come reverse proxy davanti ad Apache per servire file statici (CSS, JS, immagini) con caching aggressivo. Un CDN come Cloudflare per distribuire i contenuti statici globalmente.
• Cron ottimizzato: il cron di Moodle deve eseguirsi ogni minuto. Un cron lento o infrequente causa accumulo di task che degrada le performance. Utilizzare il parametro $CFG->task_scheduled_concurrency_limit per parallelizzare i task.

Monitoraggio e troubleshooting della cache

Una caching strategy senza monitoraggio è una bomba a orologeria. Gli strumenti essenziali:

• Redis CLI: il comando redis-cli INFO mostra statistiche chiave — hit rate (deve essere sopra il 95%), memoria utilizzata, connessioni attive, chiavi per database.
• Moodle cache admin: la pagina Amministrazione sito > Plugin > Caching > Test performance esegue benchmark sugli store configurati, mostrando latenze di lettura e scrittura.
• Grafana + Prometheus: per il monitoraggio continuo, esportare le metriche Redis in Prometheus e visualizzarle in Grafana con alert su hit rate in calo o memoria in esaurimento.
• Slow query log: abilitare il log delle query lente in MySQL per identificare operazioni che il caching non sta intercettando, segno di definizioni MUC mancanti o misconfigurazioni.

Un segnale di allarme comune: se il hit rate di Redis scende improvvisamente sotto il 90%, verificare se un plugin sta invalidando la cache troppo frequentemente o se la memoria allocata è insufficiente, causando eviction premature.

Per ottimizzare le performance LMS della tua istanza Moodle con una strategia di caching professionale, HIE Learning offre servizi specializzati di ottimizzazione Moodle: dall'audit delle performance attuali alla configurazione di Redis cache, dal tuning del database al monitoraggio continuo. Contattaci per un assessment gratuito delle performance della tua piattaforma e scopri come ridurre i tempi di caricamento fino all'80%.