En effet, la question des caches est absolument essentielle pour la gestion des performances et du "vécu" des utilisateurs sur la plate-forme.
De base, l'ensemble des caches est géré dans moodledata, et est constitué de 3 répertoires :
- cache
- localcache
- muc
L'utilisation de ces 3 répertoires est différente :
- muc : Ne contient qu'une "copie" précompilée de toutes les configurations des plugins installés. Un muc perverti peut en effet donner de grosses surprises de fonctionnement.
- cache : contient l'essentiel du cache qui doit être partagé par toutes les instances dans le cas d'une installation avec répartition de charge (les sessions et les caches de données qui concernent l'usage "collectif" des contextes de moodle, et que donc chaque utilisateur doit pouvoir consulter quelque soit son cluster d'entrée / La centralisation ne concerne encore que les installations réparties)
- localcache : la partie du cache qui peut être maintenue localement sur chaque cluster, indépendamment des autres clusters (par exemple les caches de texte ou les caches de ressources précompilées du thème, que chacun utilise mais pour sa propre navigation)
En général, sur des serveurs bas de gamme, le stockage disque est placé sur des disques SATA2 classiques, qui ont un taux d'accès assez bas (c'est encore pire sur des NAS). Si cette lenteur affecte peu les fichiers "statiques", comme un word ou un pdf à consulter de temps en temps par un étudiant, l'effet sur la performance du cache est mauvaise. Le cache est ralenti et la plate-forme peu dynamique.
Pour augmenter les performances, il y a alors 2 solutions :
- Configurer les instances de cache (là où le dit Severin) et utiliser des "serveurs de cache" (memcache et/ou memcached)
- déplacer les caches sur des systèmes de fichier plus rapide. Une bonne idée est de déplacer le cache sur un SSD annexe si on en a un à côté du stockage principal de masse. (en général on y mettra aussi tout le système d'exploitation pour les mêmes raisons)
- Encore mieux (et surtout si on a pas de SSD) : affecter une partie de sa ram à un ramdisk et poser le cache dessus (500Mo pour un petit moodle, jusqu'à 2/4G pour des gros). Le ramdisk sera le plus rapide de tous, mais a un seul inconvénient : sur linux, sa taille est fixe et il ne peut déborder. S'il déborde, le cache se bloque et .... on peut imaginer ce qui se passe.
- La restriction sur memcached est la suivante : Depuis quelques versions, moodle a ajouté le principe de gérer un memcached par cluster et effectuer une synchronisation locale de tous les memcached (pour qu'ils aient les mêmes données) au moment de l'écriture dans le cache. Chaque cluster écrira alors dans la liste de memcached (donnés par leur IP). au moment d'une écriture. (Comme on passe beaucoup plus de temps à lire le cache qu'à l'écrire, cette stratégie semble à priori meilleure qu'aller systématiquement lire dans un memcached centralisé sur un serveur tiers).
Ceci marche bien jusqu'à un certain point ; (le problème est un problème de garantie de haute disponibilité) si un seul des cluster tombe et son memcached s'arrête, alors c'est toute la plate-forme qui ne marche plus : chaque cluster essayera d'aller écrire dans le memcached éteint, et se prendra un timeout de 20 secondes QUELQUE SOIT la page.
Comme la répartition de charge sur plusieurs serveur est aussi souvent motivé par un désir de pouvoir gérer ses mises à jour système progressivement sans arrêter la plate-forme, on voit tout de suite que cette stratégie tombe à l'eau.
Pourquoi le cache est devenu si important.
Introduit vers la version 2.6, peu de données étaient cachées au départ. l'API de cache étant à la disposition des développeurs, chaque plugin peut se saisir du cache pour y cacher des données à lui. Au fil des versions de plus en plus de données y sont cachées (la structure des catégories de cours, la composition des groupes, des éléments du carnet de notes, les éléments de la banque de question etc....). Effet positif : tout un paquet de fonctionnalités n'auraient pas pu s'ajouter à moodle sans l'effet accélérateur de ces caches. Effet pervers : une stratégie de cache non optimisée conduit à des moodle qui "rament" ou dont la dynamique individuelle de page est peu dynamique et satisfaisante.
Salut à tous
Valery
