« Mettre en cache » : différence entre les versions

Dernière version du 30 avril 2021 à 07:18

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.

Un cache est un ensemble de données traitées qui sont conservées et réutilisées afin d'éviter des requêtes répétées et coûteuses dans la base de données.

Moodle 2.4 a vu l'implémentation de MUC, le Moodle Universal Cache. Ce nouveau système permet à certaines fonctions de Moodle (par exemple la récupération des chaînes de caractères) de tirer profit des différents services de cache installés (par exemple les fichiers, ram, memcached).

Dans les futures versions de Moodle, nous continuerons à étendre le nombre de fonctions Moodle qui utilisent MUC, ce qui continuera à améliorer les performances, mais vous pouvez déjà commencer à l'utiliser pour améliorer votre site.

Approche générale des tests de performance

Voici la stratégie générale que vous devriez adopter :

Construisez un environnement de test aussi proche que possible de votre instance de production réelle (matériel, logiciel, réseau, etc.)
Assurez-vous de supprimer autant de variables non contrôlées que possible de cet environnement (par exemple d'autres services)
Utilisez un outil pour placer une charge réaliste, mais simulée et répétable sur votre serveur. (par exemple jmeter ou selenium).
Décider d'une façon de mesurer la performance du serveur en capturant les données (RAM, charge, temps pris, etc.)
Exécutez votre charge et mesurez un résultat de performance de base.
Changez une variable à la fois et ré-exécutez la charge pour voir si la performance s'améliore ou se détériore. Répéter au besoin.
Lorsque vous découvrez des paramètres qui se traduisent par une amélioration constante des performances, appliquez-les à votre site de production.

Configuration du cache dans Moodle

Depuis Moodle 2.4, Moodle fournit une structure de plugin de mise en cache pour donner aux administrateurs la possibilité de contrôler où Moodle stocke les données en cache. Pour la plupart des sites Moodle, la configuration par défaut devrait être suffisante et il n'est pas nécessaire de changer la configuration. Pour les grands sites Moodle avec plusieurs serveurs, les administrateurs peuvent utiliser memcached, mongodb ou d'autres systèmes pour stocker les données du cache. L'écran du plugin de cache offre aux administrateurs la possibilité de configurer les données du cache qui sont stockées où.
. La mise en cache dans Moodle est contrôlée par ce qui est connu sous le nom de Moodle Universal Cache. Communément appelé MUC.

Ce document explique brièvement ce qu'est MUC avant d'entrer dans le détail des concepts et des options de configuration qu'il offre.

Les concepts de base du cache dans Moodle

La mise en cache dans Moodle n'est pas aussi complexe qu'il n'y paraît. Un peu de connaissance de base vous permettra de mieux comprendre le fonctionnement de la configuration du cache.

Type de caches

Commençons par les types de cache (parfois appelés mode). Il existe trois types de caches de base dans Moodle.

Le premier est le cache de l'application. C'est de loin le type de cache le plus couramment utilisé dans le code. Ses informations sont partagées par tous les utilisateurs et ses données persistent entre les demandes. L'information stockée ici est généralement mise en cache pour l'une des deux raisons suivantes : soit il s'agit d'une information requise pour la majorité des demandes et nous permet d'économiser une ou plusieurs interactions de base de données, soit il s'agit d'une information qui est consultée moins fréquemment mais qui nécessite des ressources importantes pour générer.
Par défaut, ces informations sont stockées dans une structure organisée dans votre répertoire de données Moodle.

Le deuxième type de cache est le cache de session. C'est exactement comme la session PHP que vous connaissez déjà, en fait elle utilise la session PHP par défaut. Vous vous demandez peut-être pourquoi nous avons ce type de cache, mais la réponse est simple. Le MUC fournit un moyen géré de stocker et de supprimer l'information requise entre les demandes. Il offre aux développeurs un cadre à utiliser plutôt que d'avoir à réinventer la roue et assure que nous avons accès à un moyen contrôlé de gérer le cache comme requis.
Il est important de noter qu'il ne s'agit pas d'un type de cache fréquemment utilisé car par défaut, les données du cache de session sont stockées dans la session PHP et la session PHP est stockée dans la base de données. Les utilisations du type cache de session sont limitées à de petits ensembles de données car nous ne voulons pas gonfler les sessions et donc mettre la base de données à rude épreuve.

Le troisième et dernier type est le cache de requête. Les données stockées dans ce type de cache ne persistent que pendant toute la durée de vie de la requête. Si vous êtes un développeur PHP, pensez-y comme une variable statique gérée.
> C'est de loin le moins utilisé des trois types de cache, les utilisations sont souvent limitées aux informations qui seront consultées plusieurs fois dans une même requête, généralement par plus d'une zone de code. Les informations mises en cache sont stockées en mémoire par défaut.

Types de cache et systèmes à serveurs multiples

Si vous avez un système avec plusieurs serveurs Web frontaux, le cache de l'application doit être partagé entre les serveurs. En d'autres termes, vous ne pouvez pas utiliser le stockage local rapide pour le cache de l'application, mais vous devez utiliser le stockage partagé ou une autre forme de cache partagé telle qu'un cache memc partagé.

Il en va de même pour le cache de session, à moins que vous n'utilisiez un mécanisme de "sessions bloquées" pour garantir que, dans une session, les utilisateurs accèdent toujours au même serveur frontal.

Arrière-plan de mise en cache

Les arrière-plan de cache sont l'endroit où les données sont réellement stockées. Il s'agit notamment du système de fichiers, de la session php, de Memcached et de la mémoire.
Par défaut, seuls le système de fichiers, la session php et la mémoire sont utilisés dans Moodle.
Nous n'exigeons pas qu'un site ait accès à d'autres systèmes comme Memcached. Au lieu de cela, c'est vous qui êtes responsable de l'installation et de la configuration.
Lorsque les arrière-plans de cache sont mentionnés, pensez à des systèmes en dehors de Moodle qui peuvent être utilisés pour stocker des données. Le serveur MongoDB, le serveur Memcache et les applications "serveur" similaires.

Mémoires de cache

Les mémoires de cache sont un type de plugin dans Moodle. Ils facilitent la connexion de Moodle aux arrière-plans du cache dont il a été question plus haut. Le Moodle standard a les trois valeurs par défaut mentionnées ci-dessus ainsi que Memcache, Memcached, MongoDB, Cache utilisateur APC (APCu) et Redis.

Vous pouvez trouver d'autres plugins de cache dans la base de données plugins.

Le code de ces derniers se trouve dans le cache/mémoire de votre répertoire racine de Moodle.

Dans Moodle, vous pouvez configurer autant de mémoires cache que votre architecture l'exige. Si vous avez plusieurs serveurs Memcache par exemple, vous pouvez créer une instance de cache pour chacun d'eux. Moodle contient par défaut trois instances de cache qui sont utilisées lorsque vous n'avez effectué aucune autre configuration.

Une instance de stockage de fichiers est créée qui est utilisée pour tous les caches d'applications. Il stocke ses données dans votre répertoire moodledata.
Une instance de stockage de session est créée qui est utilisée pour tous les caches de session. Il stocke ses données dans la session PHP, qui par défaut est stockée dans votre base de données.
Une instance de mémoire statique est créée qui est utilisée pour tous les types de cache de requête. Les données n'existent en mémoire que pour la durée de vie d'une requête.

Caches : ce qui se passe dans le code

Les caches sont créés en code et sont utilisés par le développeur pour stocker les données qu'il estime nécessaire de mettre en cache.
Gardons cette section agréable et courte parce que vous n'êtes peut-être pas un développeur. Il y a un point très important que vous devez savoir à propos.
Le développeur n'a pas son mot à dire sur l'endroit où les données sont mises en cache. Ils doivent spécifier les informations suivantes lors de la création d'un cache à utiliser.

Le type de cache dont ils ont besoin.
La zone de code à laquelle ce cache appartiendra (l'API si vous voulez).
Le nom de la cache, quelque chose qu'ils inventent pour décrire en un mot ce que le cache contient.

Il y a plusieurs exigences et paramètres optionnels qu'ils peuvent également spécifier, mais ne vous inquiétez pas de cela à ce stade.
Le point important est qu'ils ne peuvent pas choisir quel arrière-plan de cache utiliser, ils peuvent seulement choisir le type de cache qu'ils veulent parmi les trois détaillés ci-dessus.

Comment ils se lient entre eux

La meilleure façon de le décrire est de le faire en relation avec les rôles joués au sein d'une organisation.

L'administrateur système installe les arrière-plans de cache que vous souhaitez utiliser. Memcache, XCache, APC, etc.
Moodle n'est pas au courant, ils sont en dehors de la portée de Moodle et de la responsabilité purement de votre administrateur système.
L'administrateur de Moodle crée une instance de mémoire de cache dans Moodle pour chaque arrière-plan que le site utilisera.
Il peut y avoir une ou plusieurs instances de mémoire de cache pour chaque arrière-plan. Certains arrière-plans comme Memcached ont des paramètres pour créer des espaces séparés dans un arrière-plan.
Le développeur a créé des caches en code et les utilise pour stocker des données.
Il ne sait rien sur la façon dont vous allez utiliser vos caches, il crée juste un "cache" et dit à Moodle quel type est le mieux pour lui.
L'administrateur Moodle crée un mappage entre une instance de cache et un cache.
Ce mappage indique à Moodle d'utiliser l'arrière-plan que vous spécifiez pour stocker les données que le développeur veut en cache.

De plus, vous pouvez aller encore plus loin.

Vous pouvez mapper plusieurs caches vers une seule instance de la mémoire cache.
Vous pouvez mapper plusieurs instances de la mémoire cache vers une seule mémoire cache avec priorité (primaire... final)
Vous pouvez mapper une instance de mémoire cache comme étant la mémoire par défaut utilisée pour toutes les caches d'un type spécifique qui n'ont pas autrement de mappages spécifiques.

Si c'est la première fois que vous lisez un article sur le cache universel de Moodle, cela semble probablement assez complexe, mais ne vous inquiétez pas, il sera discuté plus en détail au fur et à mesure que nous travaillerons sur la configuration du cache dans Moodle.

Concepts avancés

Ces concepts sont des choses que la plupart des sites n'auront pas besoin de connaître ou de se préoccuper.

Vous ne devriez commencer à chercher ici que si vous cherchez à maximiser les performances sur de grands sites fonctionnant sur des services en cluster avec des arrière-plan de cache partagés, ou encore sur une architecture multi-sites où les informations sont partagées entre sites.

Verrouillage

L'idée de verrouillage n'est pas nouvelle, c'est le processus de contrôle d'accès afin d'éviter les problèmes de concurrence.

MUC a un deuxième type de plugin, un plugin de verrouillage de cache qui est utilisé lorsque les caches l'exigent. Jusqu'à présent, aucun cache n'en a eu besoin. Une cache par nature est volatile et toute information qui est absolument essentielle à la mission devrait être une base de données plus permanente, probablement la base de données.

Néanmoins, il existe un système de verrouillage que les définitions de cache peuvent exiger dans leurs options et qui sera appliqué lors de l'interaction avec une instance de mémoire cache.

Partage

Chaque bit de données qui est stocké dans un cache est associé à une clé unique calculée.
Par défaut, une partie de cette clé est l'identificateur de site qui rend tout contenu stocké dans le cache spécifique au site qui l'a stocké. Pour la plupart des sites, c'est exactement ce que vous voulez.
Cependant, dans certaines situations, il est avantageux de permettre à plusieurs sites, ou à des sites liés d'une manière ou d'une autre, de partager des données en cache. Bien sûr, tous les caches ne peuvent pas être partagés, mais certains le peuvent certainement, et en les partageant, vous pouvez encore réduire la charge et augmenter les performances en maximisant l'utilisation des ressources.

Il s'agit d'une fonctionnalité avancée, si vous choisissez de configurer le partage, veuillez le faire avec précaution.

Pour utiliser le partage, vous devez d'abord configurer des instances de cache identiques dans les sites que vous voulez partager des informations, puis sur chaque site définir le partage pour le cache à la même valeur.

Sites avec le même identifiant de site: C'est la valeur par défaut, elle permet aux sites avec le même identifiant de site de partager les informations mises en cache. C'est le plus restrictif mais il va fonctionner pour toutes les caches. Toutes les autres options comportent un élément de risque en ce sens que vous devez vous assurer que l'information contenue dans le cache s'applique à tous les sites qui y auront accès.
Sites exécutant la même version: Tous les sites accédant à l'arrière-plan qui ont la même version de Moodle peuvent partager les informations que ce cache a stockées dans la mémoire cache.
Touche personnalisée: Pour cela, vous saisissez manuellement une clé à utiliser pour le partage. Vous devez ensuite entrer exactement la même clé dans les autres sites où vous voulez partager l'information.
Tout le monde: Les données mises en cache sont accessibles à tous les autres sites qui y accèdent. Cette option place la balle entièrement dans le camp des administrateurs Moodle.

Par exemple, si vous aviez plusieurs sites Moodle ayant tous la même version sur le serveur avec APC installé, vous pourriez décider de mapper le cache de langue dans la boutique APC et de configurer le partage pour tous les sites ayant la même version.
. Le cache de langue pour les sites d'une même version est sûr à partager dans de nombreuses situations, il est utilisé sur pratiquement toutes les pages, et APC est extrêmement rapide. Ces trois points peuvent se traduire par une belle petite amélioration des performances de vos sites. Il est important de considérer avec le cache de langue qu'en le partageant entre les sites, toute personnalisation de langue sera également partagée.

L'écran de configuration du cache

L'écran de configuration du cache est votre guichet unique pour configurer la mise en cache dans Moodle.
Il vous donne un aperçu de la façon dont la mise en cache est actuellement configurée pour votre site et il fournit des liens vers toutes les actions que vous pouvez effectuer pour configurer la mise en cache selon vos besoins spécifiques.

Accès à l'écran de configuration du cache

L'écran de configuration du cache

L'écran de configuration du cache n'est accessible qu'aux utilisateurs ayant la capacité moodle/site:config. Par défaut, c'est seulement admins.
Une fois connecté à l'écran de configuration, se trouve dans Administration du site > Plugins > Cache > Configuration.

Mémoires de cache installées

Capture d'écran des mémoires cache installées

Ceci vous montre une liste des plugins de cache que vous avez installés.
. Pour chaque plugin, vous pouvez rapidement voir s'il est prêt à être utilisé (toutes les conditions php ont été remplies), combien d'instances de mémoires existent déjà sur ce site, les types de cache pour lesquels cette mémoire peut être utilisée, les fonctionnalités qu'il supporte (avancées) et les actions que vous pouvez effectuer concernant cette mémoire.

Souvent, la seule action disponible est de créer une nouvelle instance de mémoire.
. La plupart des mémoires prennent en charge les instances multiples, mais pas toutes car vous verrez que le cache de session et le cache de requête statique ne le font pas. Pour ces deux mémoires, il n'est pas logique d'avoir plusieurs instances.

Configuration des instances de la mémoire

Capture d'écran des instances de la mémoire configurées

Ici vous obtenez une liste des instances de la mémoire cache de ce site.

Nom de mémoire: Le nom donné à cette instance de la mémoire cache lorsqu'elle est créée pour que vous puissiez la reconnaître. Il peut être tout ce que vous voulez et n'est utilisé que pour que vous puissiez identifier l'instance du magasin.
Plugin: Le plugin de cache dont il s'agit est une instance.
Prêt: Une coche s'affiche lorsque toutes les exigences PHP ont été satisfaites ainsi que toutes les exigences de connexion ou de configuration ont été vérifiées.
Mappage des mémoires: Le nombre de caches auxquels cette instance de magasin a été mappée explicitement. N'inclut aucune utilisation par le biais de mappages par défaut (voir ci-dessous).
Modes: Les modes que cette instance du cache peut servir.
Soutien: Les fonctionnalités prises en charge par cette instance de la mémoire cache.
Verrouillage: Le verrouillage est un mécanisme qui limite l'accès aux données mises en cache à un seul processus à la fois pour éviter que les données ne soient écrasées. La méthode de verrouillage détermine la manière dont le verrouillage est acquis et vérifié.
Actions: Toutes les actions qui peuvent être effectuées contre cette instance de la mémoire cache.

Définitions de cache connues

Capture d'écran des définitions de cache connues

L'idée d'une définition de cache n'a pas encore été discutée ici. C'est quelque chose qui est contrôlé par le développeur. Lorsqu'ils créent un cache, ils peuvent le faire de deux façons, la première en créant une définition de cache. C'est essentiellement dire à Moodle qu'ils ont créé un cache. La deuxième façon est de créer un cache Ad hoc. Les développeurs sont toujours encouragés à utiliser la première méthode. Seuls les caches avec une définition peuvent être mappés et configurés par l'administrateur. Les caches ad hoc n'utiliseront que les paramètres par défaut.
Généralement, les caches Ad hoc ne sont autorisés que dans les situations où le cache est petit et le fait de le configurer au-delà des valeurs par défaut ne serait d'aucun avantage pour les administrateurs. C'est vraiment comme si vous disiez que l'administrateur n'a pas besoin de s'en préoccuper.

Pour chaque cache affiché ici, vous obtenez les informations suivantes :

Définition: Une description concise de ce cache.
Mode: Le type de cache pour lequel ce cache est conçu.
Composante: Le composant de code auquel le cache est associé.
Zone: La zone de code que ce cache sert dans le composant.
Mappage de mémoire: La ou les mémoires qui seront utilisées pour ce cache.
Partage: Comment le partage est-il configuré pour ce site ?
Actions: Toutes les actions qui peuvent être effectuées sur le cache. Généralement, vous pouvez modifier les mappages d'instances de la mémoire cache, modifier le partage et purger la mémoire cache.

Vous trouverez également au bas de ce tableau un lien intitulé "Redéfinir les définitions". En cliquant sur ce lien, Moodle vérifie toutes les composantes principales et les plugins installés à la recherche de modifications dans les définitions du cache.
Ceci se produit par défaut pendant la mise à niveau et si une nouvelle définition de cache est rencontrée. Cependant, si vous vous trouvez à la recherche d'un cache qui n'est pas là, cela peut valoir la peine d'être essayé.
Il est également pratique pour les développeurs car il leur permet d'appliquer rapidement les modifications lorsqu'ils travaillent avec des caches. Il est utile lors de l'ajustement des définitions de cache pour trouver ce qui fonctionne le mieux.

Des informations sur les définitions de cache spécifiques peuvent être trouvées sur la page Définitions de cache.

Résumé des instances de verrouillage du cache

Résumé des captures d'écran des instances de verrouillage du cache

Comme mentionné ci-dessus, le verrouillage de cache est un concept avancé dans MUC.
Le tableau ci-dessous donne des informations sur les mécanismes de verrouillage configurés à la disposition du MUC. Par défaut, un seul mécanisme de verrouillage est disponible, le verrouillage des fichiers. Pour l'instant, il n'y a pas de caches qui s'en servent et en tant que tel, je n'en parlerai pas plus en détail ici.

Mémoires utilisés lorsqu'il n'y a pas de mappage

Capture d'écran du mappage de la mémoire par défaut

Ce tableau montre rapidement quelles instances de la mémoire cache seront utilisées pour les types de cache s'il n'y a pas de mappages spécifiques en place.
Pour simplifier, ceci montre les mémoires cache par défaut pour chaque type.

En bas, vous remarquerez qu'il y a un lien "Modifier les mappages" qui vous amène à une page où vous pouvez configurer cela.

Ajout d'instances de mémoire cache

La configuration par défaut va fonctionner pour tous les sites, cependant vous pouvez être en mesure d'améliorer les performances de vos sites en utilisant diverses techniques de mise en cache et arrière-plan. La première chose que vous voudrez faire est d'ajouter des instances de cache configurées pour vous connecter à/utiliser les arrière-plans de cache que vous avez configurés.

Cache de fichiers

Capture d'écran de l'ajout de la mémoire cache d'un fichier

Quand sur l'écran de configuration du cache dans le tableau "Mémoire de cache installées", vous devriez être en mesure de voir le plugin de cache de fichier, cliquez sur "Ajouter une instance" pour lancer le processus d'ajout d'une instance de cache de fichier.

Lors de la création d'un cache de fichiers, il n'y a en fait qu'un seul paramètre requis, le nom de la mémoire est utilisé pour identifier l'instance de la mémoire de fichiers dans l'interface de configuration et doit être unique au site. Il peut être tout ce que vous voulez, mais nous vous conseillons d'en faire quelque chose qui décrit l'utilisation que vous avez l'intention d'utiliser la mémoire de fichiers.

Les propriétés suivantes peuvent également être spécifiées, en personnalisant l'emplacement et le fonctionnement du cache du fichier.

Chemin du cache: Permet de spécifier un répertoire à utiliser lors du stockage des données du cache sur le système de fichiers. Bien sûr, l'utilisateur sur lequel tourne le serveur web doit avoir un accès en lecture/écriture à ce répertoire. Par défaut (blanc) le répertoire Moodledata sera utilisé.
Création automatique d'un répertoire: S'il est activé lorsque le cache est initialisé si le répertoire spécifié n'existe pas, Moodle le créera. Si cela est spécifié et que le répertoire n'existe pas, le cache sera considéré comme non prêt et ne sera pas utilisé.
Mémoire de répertoire unique: Par défaut, la mémoire de fichiers créera une structure de sous-répertoires dans laquelle stocker les données. Les 3 premiers caractères de la clé de données seront utilisés comme répertoire. Ceci est utile pour éviter les limites du système de fichiers si le système de fichiers a un nombre maximum de fichiers par répertoire. En activant cette option, le cache du fichier n'utilisera pas de sous-répertoires pour le stockage des données. Cela conduit à une structure plate mais qui est plus susceptible d'atteindre les limites du système de fichiers. A utiliser avec précaution.
Pre-scanner le répertoire: L'une des caractéristiques du cache de fichier est de prévisualiser le répertoire de stockage lorsque le cache est utilisé pour la première fois. Cela permet d'accélérer le contrôle des fichiers au détriment d'une lecture approfondie.

La mémoire cache des fichiers est la mémoire par défaut utilisée pour les caches d'applications et par défaut le répertoire moodledata est utilisé pour le cache. L'accès aux fichiers peut être une ressource éprouvante en période de charge accrue et voici quelques idées pour configurer d'autres mémoires de fichiers afin d'améliorer les performances.

Tout d'abord, y a-t-il un système de fichiers plus rapide disponible sur votre serveur.
? Peut-être que vous avez un SSD installé mais que vous ne l'utilisez pas pour votre répertoire moodledata parce que l'espace est un premium.
Vous devriez envisager de créer un répertoire ou une petite partition sur votre SSD et de créer une mémoire de fichiers pour l'utiliser à la place de votre répertoire de données Moodle.

Ensuite, vous n'avez pas un lecteur plus rapide disponible pour l'utilisation, mais vous avez beaucoup d'espace libre.
Quelque chose qui pourrait valoir la peine d'être tenté serait de créer une petite partition sur le disque que vous avez installé qui utilise un système de fichiers orienté performance.
Beaucoup d'installations linux de nos jours par exemple utilisent EXT4, un système de fichiers sympa mais qui a des frais généraux dus à la journalisation.
La création d'une partition et l'utilisation d'un système de fichiers optimisé pour la performance peuvent vous donner le petit coup de pouce que vous recherchez. Rappelez-vous que les caches sont conçus pour être volatiles et choisir un système de fichiers pour un cache est une décision différente de celle de choisir un système de fichiers pour votre serveur.

Enfin, si vous êtes prêt à aller jusqu'au bout et que vous avez une abondance de mémoire sur votre serveur, vous pouvez envisager de créer un disque ramdisk/tmpfs et de pointer une mémoire de fichiers sur celui-ci. Purement basé en mémoire, il est volatil exactement comme le cache, et les performances du système de fichiers ne vont pas être bien meilleures que cela.
Bien sûr, vous serez limité dans l'espace et vous prenez essentiellement cette ressource de votre serveur.

N'oubliez pas que toutes ces idées ne sont que des idées. Quel que soit votre choix - tester, tester, tester, soyez sûr de la décision que vous prenez.

Memcache

Capture d'écran ajouter une mémoire memcache

Avant de pouvoir ajouter une instance de mémoire Memcache, vous devez d'abord avoir un serveur Memcache auquel vous pouvez accéder et avoir l'extension php Memcache installée et activée sur votre serveur web.

Comme la mémoire de fichiers, vous devez fournir le nom de la mémoire. Il est utilisé pour identifier l'instance de la mémoire dans l'interface de configuration et doit être unique au site.
. Pour une mémoire Memcache, vous devez également entrer le ou les serveurs Memcache que vous souhaitez utiliser. Les serveurs doivent être ajoutés un par ligne et chaque ligne peut contenir 1 à 3 propriétés séparées par des deux-points.

L'URL ou l'adresse IP du serveur (obligatoire)
Le port sur lequel le serveur écoute (facultatif)
Le poids à donner à ce serveur (facultatif)

Par exemple, si vous aviez deux instances Memcached en cours d'exécution sur votre serveur, l'une configurée pour le port par défaut et l'autre pour 11212, vous utiliseriez ce qui suit :

127.0.0.1 127.0.0.1:11212

En option, vous pouvez également spécifier un préfixe de clé à utiliser. Ce que vous entrez ici sera préfixé sur toutes les clés avant d'accéder au serveur et peut être utilisé pour répartir efficacement l'espace Memcache d'une manière reconnaissable. Ceci peut être pratique si vous avez un outil de gestion pour votre serveur Memcache que vous utilisez pour inspecter ce qui y est stocké.

Remarques importantes sur la mise en œuvre

L'extension Memcache ne permet pas de supprimer un ensemble de données. Soit une seule donnée est supprimée, soit toutes les données sont supprimées.
Pour cette raison, il est important de noter que lorsque vous purgez une mémoire Memcache dans Moodle, il supprime toutes les données dans l'arrière-plan Memcache. Pas seulement ceux relatifs à Moodle.
Pour cette raison, il est fortement recommandé d'utiliser des serveurs Memcache et de configurer tout autre logiciel pour utiliser ces serveurs. Cela pourrait entraîner une dépréciation du rendement et des effets néfastes.
De même, si vous voulez utiliser Memcache pour la mise en cache et pour les sessions dans Moodle, il est essentiel d'utiliser deux serveurs Memcache. Un pour les sessions, et un pour la mise en cache. Sinon, une purge de cache dans Moodle purgera vos sessions !

Memcached

Capture d'écran ajouter une mémoire Memcached

Comme la mémoire Memcached, vous devez d'abord avoir un serveur Memcached auquel vous pouvez accéder et avoir l'extension php Memcached installée et activée sur votre serveur.

Tout comme la mémoire Memcached, il y a deux paramètres nécessaires à la configuration d'une mémoire Memcached.

Nom de mémoire: Il sert à identifier l'instance du point de vente dans l'interface de configuration et doit être unique au site.
Serveurs: Les serveurs que vous souhaitez que cette mémoire cache utilise. Voir ci-dessous pour plus de détails.

Les serveurs doivent être ajoutés un par ligne et chaque ligne peut contenir 1 à 3 propriétés séparées par des deux-points.

L'URL ou l'adresse IP du serveur (obligatoire)
Le port sur lequel le serveur écoute (facultatif)
Le poids à donner à ce serveur (facultatif)

Par exemple, si vous aviez deux instances Memcached en cours d'exécution sur votre serveur, l'une configurée pour le port par défaut et l'autre pour 11212, vous utiliseriez ce qui suit : 127.0.0.1 127.0.0.1:11212

Il y a aussi plusieurs paramètres optionnels que vous pouvez régler lors de la création d'une mémoire Memcached.

Utiliser la compression: La valeur par défaut est true, mais peut être désactivée si vous le souhaitez.
Utiliser le sérialiseur: Permet de sélectionner le sérialiseur utilisé pour communiquer avec le serveur Memcached. Par défaut, l'extension Memcached et PHP ne fournissent qu'une seule version sérialisée, mais il y en a quelques autres disponibles pour l'installation si vous allez les chercher. L'un d'eux, par exemple, est l'igbinaire que l'on peut trouver à l'adresse https://github.com/igbinary/igbinary.
Préfixe de clé: Permet de définir certains caractères qui seront préfixés sur toutes les touches avant d'interagir avec le serveur.
Méthode de hachage: La méthode de hachage fournie par l'extension Memcached est utilisée par défaut ici. Toutefois, vous pouvez choisir d'utiliser une alternative si vous le souhaitez. http://www.php.net/manual/en/memcached.constants.php fournit quelques informations sur les options disponibles. Veuillez noter que si vous le souhaitez, vous pouvez également remplacer la fonction de hachage par défaut que PHP utilise dans votre php.ini.
Tampon écrit: Désactivé par défaut, et pour de bonnes raisons. L'activation des écritures mises en mémoire tampon minimise l'interaction avec le serveur Memcached en mettant en mémoire tampon les opérations io. L'inconvénient est que sur un système avec n'importe quelle simultanéité, il y a de fortes chances que des requêtes multiples finissent par générer les données parce que personne ne les a poussées vers le serveur Memcached quand ils les ont demandées pour la première fois. L'activation de cette fonction peut être avantageuse pour les caches qui ne sont accessibles que dans des zones à capacité contrôlée, par exemple lorsque l'interaction multiple pèse sur les ressources réseau ou autres. Mais c'est certainement à l'extrémité extrême de l'échelle de l'ajustement.

Remarques importantes sur la mise en œuvre

L'extension Memcached ne permet pas de supprimer un ensemble de données. Soit une seule donnée est supprimée, soit toutes les données sont supprimées.
.

Pour cette raison, il est important de noter que lorsque vous purgez une mémoire Memcached dans Moodle, il supprime toutes les données du serveur Memcached. Pas seulement celles relatives à Moodle.
Pour cette raison, il est fortement recommandé d'utiliser des serveurs dédiés Memcached et de ne pas configurer d'autres logiciels pour utiliser les mêmes serveurs. Cela pourrait entraîner une dépréciation du rendement et des effets néfastes.

De même, si vous voulez utiliser Memcached pour la mise en cache et pour les sessions dans Moodle, il est essentiel d'utiliser deux serveurs Memcached. Un pour les sessions, et un pour la mise en cache. Sinon, une purge de cache dans Moodle purgera vos sessions !

MongoDB

Capture d'écran ajouter une mémoire MongoDB

MongoDB est une base de données NoSQL orientée document open source. Visitez leur site web www.mongodb.org pour plus d'informations.

Nom de mémoire: Utilisé pour identifier l'instance de mémoire dans l'interface de configuration et doit être unique au site.
Serveur: C'est la chaîne de connexion pour le serveur que vous voulez utiliser. Plusieurs serveurs peuvent être spécifiés à l'aide d'une liste séparée par des virgules.
Base de donnée: Le nom de la base de données à utiliser.
Nom d'utilisateur: Le nom d'utilisateur à utiliser pour établir une connexion.
Mot de passe: Le mot de passe de l'utilisateur utilisé pour la connexion.
Jeu de répliques: Le nom de la réplique à laquelle se connecter. Si cela est donné, le maître sera déterminé en utilisant la commande de base de données ismaster sur les graines, de sorte que le pilote peut finir par se connecter à un serveur qui n'a même pas été listé.
Utilisation: Si cette option est activée, l'option usesafe sera utilisée pendant les opérations d'insertion, de récupération et de suppression. Si vous avez spécifié un jeu de répliques, celui-ci sera de toute façon forcé.
Utiliser une valeur sûre: Vous pouvez choisir de fournir une valeur spécifique pour une utilisation sûre. Cela déterminera le nombre de serveurs sur lesquels les opérations doivent être terminées avant qu'elles ne soient réputées terminées.
Utiliser les touches étendues: Si cette option est activée, les jeux de clés complets seront utilisés lors du travail avec le plugin. Ceci n'est pas encore utilisé en interne, mais vous permet de rechercher et d'explorer facilement le plugin MongoDB manuellement si vous le souhaitez. L'activation de cette fonction ajoutera un léger surcoût et ne devrait donc être effectuée que si vous en avez besoin.

Mappage d'un cache à une instance de mémoire

Capture d'écran mappage de mémoire de définition de cache

Mapper une instance de mémoire à un cache indique à Moodle d'utiliser cette instance de magasin lorsque le cache est en interaction avec lui. Cela permet à l'administrateur de Moodle de contrôler où les informations sont stockées et surtout d'optimiser les performances de votre site en tirant le meilleur parti des ressources disponibles pour votre site.

Pour définir un mappage, naviguez d'abord jusqu'à l'écran de configuration du cache. Procédez à la recherche de la table "Définitions connues du cache" et dans celle-ci, trouvez le cache que vous souhaitez mapper. Dans la colonne des actions, sélectionnez le lien pour Modifier les mappages.

L'écran qui s'affiche vous permet de mapper une ou plusieurs instances du cache à utiliser par ce cache. Plusieurs menus déroulants s'affichent qui vous permettent de mapper un ou plusieurs caches. Tous les caches mappés interagissent avec. La mémoire "Primaire" est la mémoire qui sera utilisée en premier lors de l'interaction avec le cache. La mémoire mappée "Finale" sera la dernière mémoire cache interagissant avec.
. La façon dont cette interaction se produit est documentée ci-dessous.

Si aucune mémoire n'est mappée pour le cache, les mémoires par défaut sont utilisées. Consultez la section ci-dessous pour plus d'informations sur la modification des mémoires par défaut.

Si une seule instance de stockage est mappée au cache, les événements suivants se produisent :

Obtenir des données du cache: Moodle demande au cache d'obtenir les données. Le cache tente de l'obtenir de la mémoire. Si la mémoire les a, il les donne au cache, et le cache les donne à Moodle pour qu'il puisse utiliser les données. Si la mémoire ne les a pas, l'échec est renvoyé et Moodle devra générer les données et les enverra très probablement dans le cache.
Stockage des données dans le cache: Moodle demandera au cache de stocker certaines données, et le cache les donnera à la mémoire cache.

Si plusieurs instances de mémoire sont mappées au cache, les événements suivants se produisent :

Obtenir des données d'une mémoire: Moodle demande au cache d'obtenir les données. Le cache tente de l'obtenir à partir de la première mémoire. Si la première mémoire les a alors il renvoie les données au cache et le cache les renvoie à Moodle. Si la première mémoire n'a pas les données, il tente d'obtenir les données de la deuxième mémoire. Si la deuxième mémoire les a, il les renvoie à la première mémoire qui les stocke lui-même avant de les renvoyer dans le cache. Si ce n'est pas le cas, la mémoire suivante est utilisée. Ceci continue jusqu'à ce que les données soient trouvées ou qu'il n'y ait plus de mémoire à vérifier.
Stockage de données dans le cache: Moodle demandera au cache de stocker certaines données, le cache les donnera à chaque mémoire cache mappée pour stockage.

Le principal avantage de l'attribution de plusieurs mémoires est que vous pouvez introduire la redondance du cache. Bien sûr, cela implique une surcharge, donc il ne devrait être utilisé que lorsque cela est réellement nécessaire. L'exemple suivant est un exemple de cas où le mappage de plusieurs mémoires peut constituer un avantage :

Scénario:
Vous avez un serveur web qui a un site Moodle ainsi que d'autres sites.
Vous avez également un serveur Memcache qui est utilisé par plusieurs sites dont Moodle.

Memcache a un cache de taille limitée, qui lorsqu'il est plein et demandé de stocker plus d'informations libère de l'espace en laissant tomber les entrées de cache les moins utilisées.

Vous voulez utiliser Memcache pour votre site Moodle parce qu'il est rapide, mais vous êtes conscient qu'il peut introduire plus d'erreurs de cache car c'est un serveur Memcache très utilisé.

Solution:

Pour contourner ce problème, mappez deux mémoires vers les caches Memcache que vous souhaitez utiliser.
Faites de Memcache la mémoire principale, et faites de la mémoire de fichiers par défaut la mémoire de cache final.

Explication:

En faisant cela, vous avez créé une redondance, quand quelque chose est demandé Moodle essaie d'abord de l'obtenir de Memcache (la mémoire la plus rapide) et si ce n'est pas là il procède à la vérification du cache du fichier.

Encore quelques points d'intérêt :

Mapper plusieurs caches introduira des frais généraux, plus il y aura de caches mappés, plus il y aura de frais généraux.
Considérez les mémoires cache vers lesquelles vous mappez, si les données restent là une fois définies, il n'y a plus de raison de mapper d'autres mémoires après elles. Cette technique est surtout utile dans les situations où il n'est pas garanti que les données resteront après avoir été définies.
Testez toujours votre configuration. Activez l'affichage des informations de performance, puis regardez quelles mémoires sont utilisés lors de l'interaction avec Moodle de manière à déclencher le cache.

Réglage des mémoires qui sont utilisées en l'absence de mappage

Capture d'écran réglage des mémoires qui sont utilisées en l'absence de mappage

Il s'agit en fait de définir les mémoires par défaut qui sont utilisées pour un type de cache lorsqu'il n'y a pas de mappage spécifique qui a été fait pour elle.

Pour définir un mappage, naviguez d'abord jusqu'à l'écran de configuration du cache. Poursuivre pour trouver les mémoires utilisées en l'absence de mappage. Après le tableau, vous trouverez un lien Modifier les mappages, cliquez sur ce lien.

Sur l'écran qui s'affiche, vous pouvez sélectionner un magasin pour chaque type de cache à utiliser lorsqu'un cache du type correspondant est initialisé et qu'il n'y a pas de correspondance explicite pour lui.

Notez que sur cette interface, les menus déroulants ne contiennent que les instances de mémoire qui conviennent au mappage avec le type. Toutes les instances ne seront pas nécessairement affichées. Si vous avez une instance de mémoire que vous ne voyez pas, alors elle ne convient pas pour TOUTES les définitions de cache qui existent.
. Vous ne pourrez pas faire de cette instance de mémoire l'instance par défaut, vous devrez plutôt la mapper explicitement à chaque cache que vous voulez/pouvez utiliser.

Configuration de la mise en cache pour votre site

C'est là que ça devient vraiment délicat, et malheureusement il n'y a pas de guide étape par étape à ce sujet.

La meilleure façon de configurer la mise en cache d'un site dépend entièrement du site en question et des ressources dont il dispose.

Ce que l'on peut vous offrir, ce sont des trucs et des astuces pour vous aider à réfléchir et peut-être à présenter des idées qui vous aideront en cours de route.

Si vous lisez ce document et que vous avez appris une chose ou deux sur la configuration de la mise en cache sur votre site, partagez vos connaissances en ajoutant des points ici.

Planifiez-le. C'est une chose complexe. Vous aurez besoin de : comprendre votre site, comprendre votre système, et vraiment comprendre le comportement des utilisateurs.
Si vous avez un petit site, les gains ne sont pas susceptibles d'être significatifs, si vous avez un grand site obtenir ce droit peut conduire à une amélioration substantielle des performances.
En effet les arrière-plans de cache recherchent vraiment les avantages et les inconvénients de chacun. Gardez à l'esprit votre site lorsque vous pensez à eux. Selon votre site, il se peut qu'il n'y ait pas un seul arrière-plan de cache pour répondre à tous les besoins de votre site et que vous bénéficierez de quelques arrières-plans à votre disposition.
Les choses ne sont généralement pas aussi simples que l'installation d'un arrière-plan de cache et son utilisation. Faites attention à la configuration et essayez de l'optimiser pour votre système. Testez-le séparément et comprenez ses performances avant d'en avertir Moodle. Le cache vous permet de déplacer la charge de la base de données et de réduire le traitement des requêtes de pages.
Si par exemple vous avez Memcache installé mais que votre connexion n'a pas été optimisée pour cela, vous pourriez bien vous retrouver dans une situation de perte avant même de parler du serveur Memcache à Moodle.

Lorsque vous considérez les instances par défaut de votre mémoire, gardez à l'esprit qu'elles doivent fonctionner avec des ensembles de données de tailles et de fréquences variables. Pour un grand site, votre meilleur choix est de regarder chaque définition de cache et de la mettre en correspondance avec une mémoire qui convient le mieux aux données qu'il contient et à la fréquence d'accès.
Les définitions de cache ont été documentées Définitions de cache.
Encore une fois, lorsque vous mappez les instances de mémoire aux caches, pensez vraiment au cache que vous mappez et prenez une décision basée sur ce que vous comprenez de votre site et ce que vous savez sur le cache.
Les définitions de cache ont été documentées Définitions de cache.
Testez votre configuration. Si vous pouvez faire un test de performance c'est encore mieux ! Si vous activez les informations de performance, Moodle imprimera également les informations d'accès au cache en bas de l'écran. Vous pouvez l'utiliser pour vérifier visuellement que le cache est utilisé comme vous l'attendez, et il vous donnera une indication de l'endroit où se produisent les erreurs, etc.
Gardez un œil sur votre arrière-plan. Moodle ne fournit pas un moyen de surveiller un arrière-plan de cache et c'est certainement quelque chose que vous devriez garder un œil dessus. Memcache par exemple laisse tomber les données les moins utilisées lorsqu'elles sont pleines pour faire place à de nouvelles données. Par contre, APC cesse d'accepter les données lorsqu'elles sont pleines. Les deux auront un impact sur votre performance si vous êtes complet et vous allez rencontrer des ratés. Cependant quand APC est plein c'est horrible, mais il est beaucoup plus rapide.

En savoir plus sur les tests de performance

Deux liens qui pourraient être utiles à quiconque envisage de tester les performances sur ses propres serveurs :

Conseils de performance pour les serveurs Web à répartition de charge équilibrée

Dans Moodle 2.4 et suivants avec des serveurs Web à répartition de charge équilibrée, n'utilisez pas l'option de mise en cache par défaut qui stocke les données dans les données Moodle sur un disque réseau partagé. Utilisez plutôt memcached. Voir l'article de Tim Hunt sur http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html
Dans Moodle 2.6 et suivants, assurez-vous de définir $CFG->localcachedir dans un répertoire local dans config.php (pour chaque noeud). Cela accélérera une partie de la mise en cache du disque qui se produit en dehors de MUC, comme les thèmes, javascript, bibliothèques, etc.

Résolution des problèmes

Avez-vous rencontré un problème ou vous êtes-vous retrouvé dans une énigme ? La réponse se trouve peut-être dans cette section. Si ce n'est pas le cas, quand vous trouvez une réponse, pourquoi ne pas la partager ici.

Plus d'informations

Définitions de cache Informations sur les définitions de cache trouvées dans Moodle.
Cache API Détails du cache API.
Cache API - Référence rapide Une courte page centrée sur le code du cache API.
The Moodle Universal Cache (MUC) La spécification de cache d'origine.

Discussions liés au cache qui peuvent aider à comprendre le MUC sur les forums de discussion :

Autre :

Moodle 2.4.5 vs. 2.5.1 performance et mémoire cache MUC APC article du blog de Justin Filip

Voir aussi

FAQ sur Moodle Unified Cache

Documentation

« Mettre en cache » : différence entre les versions

Dernière version du 30 avril 2021 à 07:18

Sommaire

Approche générale des tests de performance

Configuration du cache dans Moodle