FAQ sur Moodle Unified Cache

Remarque : la traduction de cette page n'est pas terminée. N'hésitez pas à traduire tout ou partie de cette page ou à la compléter. Vous pouvez aussi utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.


Le Moodle Unified Cache (MUC) lors de l'inspection initiale peut sembler être une bête complexe et rebutante, ce qui peut conduire à l'ignorer ou, comme c'est souvent le cas, à une mauvaise configuration.

Voici ce que vous devez savoir (pour que vous puissiez ignorer le reste).

Qu'est-ce que le MUC?

Le MUC est un cache, un cache est une mémoire de données qui est plus facile/plus rapide à récupérer que si elle venait de sa source. Il économise l'effort (informatique) et rend Moodle plus rapide.

Devrais-je utiliser le MUC ?

Oui, et les sites utilisant Moodle 2.4 ou supérieur utilisent déjà le MUC.

Si un site fonctionne déjà bien, considérez ne rien changer comme "l'optimisation prématurée est la racine de tout le mal".

Par défaut, MUC utilise le système de fichiers pour stocker ses objets mis en cache, ce qui accélère déjà les choses par rapport à l'utilisation sans MUC du tout. En configurant davantage le MUC, nous essayons simplement de le rendre plus rapide.

Qu'est-ce qui ne va pas avec le système de fichiers par défaut MUC ?

Pas grand-chose du tout, mais les performances de la MUC dépendent de la vitesse de lecture/écriture de son support de stockage.

En général, les disques sont lents mais sûrs (persistants). Les données MUC n'ont pas besoin d'être conservées en toute sécurité car elles peuvent toujours être régénérées et peuvent donc se permettre d'être conservées dans un endroit rapide mais volatile, comme la RAM.

Comment puis-je rendre le MUC plus rapide ?

L'utilisation d'un cache basé sur la RAM est la meilleure façon de rendre le MUC rapide et il existe quelques outils que nous pouvons utiliser pour cela, tels que tmpfs, Memcached, APC, Redis et les heures supplémentaires probablement plus... Un bon point de départ si vous n'êtes pas sûr de vos besoins spécifiques est Memcached car il est commun, bien testé, rapide et facile à déployer.

Comment déployer Memcached ?

Ceci n'est en aucun cas exhaustif, et variera en fonction de l'OS, etc. Mais pour des raisons de simplicité...

  • Installer Memcached et son support PHP d'une manière compatible avec le système d'exploitation, par exemple dans Debian/Ubuntu.
 apt-get install memcached php5-memcached
  • Configurez Memcached, ou au moins prenez connaissance de sa configuration par défaut, par ex :
    • 64 Mo de mémoire vive allouée
    • Fonctionne sur le port 11211
  • Dans Moodle allez à
    • Administration du site > Plugins > Mettre en cache > Configuration
    • Sous Mémoires de cache installés, recherchez Memcached et cliquez sur l'action Ajouter une instance.
    • Donnez un nom à la mémoire, comme "Memcached_MUC".
    • Dans serveur, en supposant la configuration de base ci-dessus, tapez "localhost". "'Enregistrer les modifications"'.
    • Faites défiler jusqu'au bas de la page Administration du cache.
    • Sous Mémoires utilisées en l'absence de mappage, cliquez sur Modifier les mappages.
    • Dans le menu déroulant Application, sélectionnez le nom des caches. "'Enregistrer les modifications'".
  • Profit

Voir Mettre en cache pour plus de détails.

Combien de mémoire dois-je allouer à MUC ?

La valeur par défaut sur la plupart des déploiements Memcached est de 64 Mo et c'est probablement "'plus'" que suffisant pour une installation Moodle standard. A titre d'exemple, la vérification d'un site en direct avec environ 6000 connexions d'utilisateurs individuels au cours des dernières 24 heures, l'utilisation de Memcached MUC était d'environ 11MB (Moodle 2.8 avec 26 plugins supplémentaires).

Le plus important lors de l'implémentation d'un cache en mémoire tel que Memcached est de surveiller et de comprendre son utilisation dans votre propre déploiement car les exigences peuvent varier énormément.

J'utilise déjà Memcached pour des sessions, puis-je le réutiliser ?

Non, j'ai bien peur que non. Si le MUC purge ainsi les sessions, tous les utilisateurs seront déconnectés. Deux instances Memcached sont nécessaires dans ce scénario, une pour les sessions et un MUC. Vous trouverez un exemple de la façon de procéder ici.


Comment puis-je savoir quel mémoire Cache j'utilise vraiment ?

Cacheused.png

Activer temporairement le débogage de performance à

Développement de l'administration du site > Débogage > Info performance.

Ceci ajoute des informations utiles au pied de page de toutes les pages (si votre thème le supporte), y compris les objets MUC et la mémoire cache d'où ils viennent.

J'ai un cluster de serveurs, <d'autres questions ici> ?

Vous êtes probablement au-delà du public cible de cette FAQ en termes de votre foo d'administration système.

C'est quoi ce petit triangle gris ?

Nomap.png

Ceci apparaît sous Stockages utilisés en l'absence de mappage lorsque le mappage par défaut du cache de l'application ne prend pas en charge une exigence d'une ou plusieurs des définitions de cache.

Par exemple, parmi les caches d'applications par défaut, Invalidation d'événement n'est pas supporté par Memcached. En effet, l'invalidation d'événement nécessite une '"garantie de données"' qui garantit l'existence des données dans le cache une fois qu'elles y sont placées. Il n'est jamais nettoyé pour libérer de l'espace ou parce qu'il n'a pas été utilisé récemment. Comme Memcached expulse les objets de son cache, il ne peut pas être utilisé pour l'invalidation d'événements.

Ce n'est pas un problème car l'invalidation d'événement utilisera simplement le cache du système de fichiers, ou si spécifié un cache d'application secondaire compatible, ou un cache alloué directement à la définition Invalidation d'événement.

Où puis-je trouver plus de documentation sur la mise en place du MUC ?

Voir Mettre en cache.

Si vous êtes plus intéressé par les détails du système de cache, par exemple les caractéristiques du cache (ttl, garantie des données, etc), le développeur API est à consulter.

Voir aussi