Moodle e Redis, un test sul campo

Se per siti di e-commerce il monitoraggio e l'ottimizzazione delle prestazioni rappresenta un requisito fondamentale, grazie anche alla rilevanza di certi numeri nella SERP, per l’e-learning lo scenario è diverso. Spesso ci si affida ai feedback degli utenti e, se nessuno si lamenta, si dà per scontato che tutti navigano rapidamente e che il sito abbia tempi di risposta adeguati. I feedback degli utenti non mettono però al riparo da situazioni di emergenza. Un esempio tipico è un e-learning che eroga crediti da fruire entro il 31/12 e che, negli ultimi giorni dell’anno, riceve picchi di traffico pari a quelli di tutti i mesi precedenti messi insieme. A quel punto ci si accorge che la macchina è sotto carico e sottodimensionata. Best practice come il caching diventano essenziali, assieme a un’accurata analisi con il service provider del servizio hosting o cloud.

A proposito di caching, un aiuto molto efficace arriva da sistemi integrativi rispetto a quanto già offerto da Moodle. Tra questi, Redis è una soluzione molto potente: si tratta di un motore di memorizzazione in memoria (in-memory database) estremamente veloce, che permette di conservare dati e strutture complesse direttamente in RAM, riducendo il carico sul database e velocizzando le operazioni ripetitive. L’integrazione con Moodle è ormai stabile e consente, con poche righe di configurazione, di agganciarsi al motore Redis e mettere letteralmente il turbo alla piattaforma.

Ho voluto testare sul campo il sistema di caching predefinito di Moodle e metterlo a confronto con Redis. La base è stata un e-learning con oltre 25mila utenti, quindi ben movimentato. Ho utilizzato un semplicissimo server locale, senza alcuna ottimizzazione aggiuntiva. Ecco il responso:

• Su qualsiasi pagina, Redis ha portato un miglioramento sensibile, proporzionale alla complessità della pagina stessa.
• Su “My Courses”, i tempi richiesti dalle query sono stati complessivamente di 0,092 ms con la cache base e 0,076 ms con Redis, con un miglioramento del 17%.
• Nella homepage di un corso con diverse unità, il miglioramento ha sfiorato il 40%, passando da 0,174 ms a 0,106 ms.
• Ottime, e fondamentali, le prestazioni su due pagine complesse: il report di completamento attività (da 0,877 a 0,564 ms) e il report delle risposte al quiz finale (da 4,807 a 3,056 ms), entrambe con circa 35% di miglioramento.

Queste pagine sono tipici esempi di carico che possono mandare in crisi Moodle nei periodi di picco di utenze. Ridurre i tempi anche di secondi significa meno processi PHP simultanei, meno query concorrenti al database e minor rischio di saturazione di MySQL.

Il tutto, con poche righe di configurazione. Vale la pena ricordare che tra gli oggetti più complessi usati da Moodle c’è course_modinfo, un mega-object che contiene informazioni sul corso, permessi contestuali, criteri di completamento e metadata. Poter memorizzare in cache un oggetto di questo tipo è un vantaggio enorme, e in pratica spiega gran parte del miglioramento osservato sulle pagine più pesanti.