Object cache/fr

MediaWiki utilise la mise en cache pour un grand nombre d'éléments et à différents niveaux. Cette page documente les différents caches utilisés dans l'application PHP MediaWiki.

Généralités
Il existe deux types de dépôts décrits dans le contexte des caches d'objets de MediaWiki :


 * 1) le cache : c'est un endroit pour ranger le résultat d'un calcul, ou des données récupérées d'une source externe (afin d'en accélérer l'accès). C'est un « cache » au sens utilisé en informatique.
 * 2) La zone de réserve est un endroit où l'on stocke des données en petites quantités et qui ne se trouvent pas ailleurs. Connu également comme stash (ou « magot  » d'objets). Ce sont les valeurs qu'il n'est pas possible (ou pas permis) de recalculer à la demande.

Terminologie
Une clé de cache est dite « vérifiable  »  si le programme est capable de vérifier que la valeur n'est pas obsolète.

Ceci ne s'applique que si une clé possède une valeur unique, comme le calcul du 100e chiffre de Pi qui peut être mis en cache avec la clé. Le résultat peut être rangé de manière sécurisée dans un dépôt à accès rapide sans coordination car il ne sera jamais mis à jour ni effacé. Si le contenu du cache expire, il peut être réévalué et produit le même résultat. On applique le même raisonnement pour enregistrer le wikicode d'une version (revision) donnée d'une page. La révision 123 est apparue et aura toujours le même contenu. Si le programme connait l'ID de la version cherchée, une clé de cache comme  peut aussi être une clé de cache vérifiable.



Enregistrement des données structurées
MediaWiki prend en charge l'enregistrement à la fois des valeurs primitives (booléens, entiers, chaînes) et des structures de tableaux (éventuellement imbriqués). Il est aussi techniquement possible d'enregistrer les objets plats (stdClass) et les instances de classes arbitraires, en s'appuyant sur la sérialisation PHP, mais ceci est obsolète pour des raisons de sécurité (T161647) et de stabilité, car il est très difficile de modifier une classe de sorte à ne pas rompre la compatibilité avant ou arrière avec les objets de cette classe se trouvant dans le cache (comme T264257, etc.).

Le code qui écrit ou qui lit dans un cache doit être à la fois compatible avant et arrière. Typiquement, les données en cache de la lecture du code ont la même valeur ou une valeur plus actuelle que le code qui les a placées dans le cache (impliquant la compatibilité arrière de la logique de lecture, ou la compatibilité avant de l'écriture anticipée), mais il existe deux scrénarii importants où le contraire est également souhaité :
 * 1) Pendant un déploiement, les différents serveurs et les centres de données pendant un court instant sont en train d'exécuter les anciennes versions en parallèle avec les nouvelles et la même base de données partagées avec les mêmes services de cache. Ainsi pendant ce temps, on peut très bien écrire dans le cache et y lire les anciennes versions et les nouvelles, de manière concurrente.
 * 2) Les opérateurs de sites doivent pouvoir restituer le dernier déploiement ou revenir à la précédente version du logiciel.

Bonnes pratiques :


 * Eviter de placer les constantes des versions dans les clés du cache. Utilisez le terme  avec son option version, qui gère automatiquement la compatibilité avant et arrière, et qui invalide les clés du cache en fonction des versions du logiciel.
 * Eviter d'enregistrer des objets de classes. Enregistrer des primitives ou des tableaux (imbriqués) de primitives. Les classes doivent être converties en - et à partir de - tableaux simples, et enregistrées soit comme des tableaux simples, ou comme une chaîne de caractères au format JSON. L'encodage et la sérialisation de ceux-ci doivent être faits par le consommateur et cela n'est pas fait par exemple, par les interfaces BagOStuff ou WANObjectCache. (A l'avenir, MediaWiki pourra faire cela automatiquement pour les classes implémentant JsonUnserializable, apparu avec MediaWiki 1.36).

Services
Voici les dépôts abstraits disponibles pour les fonctionnalités de MediaWiki, voir la section Utilisation pour les exemples.



Serveur local

 * Accédé via.
 * Configurable : non (détecté automatiquement).
 * Comportement : très rapide (<0.1 ms, à partir de la mémoire locale), faible capacité, non partagé entre les serveurs d'applications.

Les valeurs dans ce dépôt ne sont conservées que dans la RAM locale des serveurs web (typiquement en utilisant php-apcu). Elles ne sont pas dupliquées sur les autres serveurs ou dans les grappes, et ne possèdent pas d'options pour synchroniser la mise à jour ou l'effacement.

Si le serveur web n'a pas installé php-apcu (ou son équivalent), cette interface se replie vers un bouchon vide dans lequel aucune clé n'est stockée. Il est également initialisé sur une interface vide pour les scripts de maintenance et les autres modes en ligne de commande. MediaWiki prend en charge APCu, et WinCache.



Grappe locale (cluster)

 * Accédé via.
 * Configurable : oui, via $wgMainCacheType.
 * Comportement : rapide (environ 1 ms, d'après le service de la mémoire), capacité moyenne, partagé entre les serveurs d'applications mais non répliqué sur les centres de données.

La plupart du temps pour usage interne seulement, pour offrir la coordination limitée des actions à l'intérieur d'un centre de données particulier. Ceci utilise le même espace de stockage serveur que le cache WAN, mais avec un espace de noms différent pour les clés, et sans aucune possibilité de diffuser les demandes de suppression aux autres centres de données.

Le cache local des grappes est typiquement sauvegardé par Memcached, mais peut aussi utiliser la base de données.



Cache WAN

 * Accédé via.
 * Configurable : oui, via $wgMainWANCache, dont la valeur par défaut est $wgMainCacheType.
 * Comportement : rapide (environ 1 ms, d'après le service de la mémoire), capacité moyenne, partagé entre les serveurs d'applications, avec les événements d'invalidation répliqués sur les centres de données.

Les valeurs de ce dépôt sont rangées d'une manière centralisée dans le centre de données actuel (typiquement en utilisant Memcached en tant que base arrière). Alors que les valeurs ne sont pas répliquées sur les autres grappes, les événements de suppression (delete) et de purge des clés sont diffusés sur les autres centres de données pour l'invalidation des caches. Voir la page de référence de la classe WANObjectCache pour l'utilisation.

En résumé : calculez et rangez les valeurs via la méthode. Pour invalider les caches, utilisez la purge des clés (et non pas l'initialisation directe de la clé).

Voir aussi WANObjectCache sur wikitech.wikimedia.org.



Zone de réserve principale (stash)

 * Accédé via.
 * Configurable : oui, via $wgMainStash.
 * Comportement : peut impliquer une lecture disque (de 1 à 10 ms), semi-persistant, partagé entre les serveurs d'applications et répliqué sur les centres de données.

Les valeurs de ce dépôt sont lues et écrites dans le même centre de données, en souhaitant que les écritures soient répliquées vers d'autres centres de données mais proviennent aussi des autres données ces centres. Utilise typiquement MySQL comme base arrière. (See MariaDB for Wikipedia's configuration.) Par défaut la table est utilisée. Il faut accepter que les lectures puissent potentiellement se bloquer, par exemple parce que les écritures dans le cache sont suspendues, ou pour des raisons de collision quand des requêtes se superposent et se terminent de manière désynchronisées, ou à cause d'écritures venant d'un autre centre de données qui aurait une latence d'une seconde pour répliquer.

Ce dépôt est supposé avoir une persistence forte et il est souvent utilisé pour les données qui ne peuvent pas être regénérées et que l'on ne retrouve pas ailleurs. Néanmoins les données stockées dans la réserve principale (Mainstash) doivent être non critiques et avoir un impact utilisateur minimal en cas de perte, permettant ainsi à la base arrière de devenir quelque fois partiellement indisponible ou effacée en cas de pression opérationnelle, sans provoquer d'incidents.

Utilisation


Enregistrement des sessions
Ceci n'est pas réellement un cache, dans le sens où les données sont enregistrées nulle part ailleurs.
 * Accédé via les objets, eux-même accédés via le SessionManager, ou
 * Configuré via.



Cache interwiki
Voir le Cache interwiki pour les détails, et aussi.



Cache de l'analyseur syntaxique
Voir le Cache de l'analyseur pour les détails. Voir également purgeParserCache.php.
 * Accédé via la classe.
 * La base arrière est configurée par (typiquement MySQL).
 * Les clés sont canoniques et fonction de l'ID des pages et populées quand une page est analysée.
 * L'ID de révision est vérifié lors la récupération.



Cache des messages

 * Accès via.
 * Configurable en base arrière par $wgMessageCacheType (la valeur par défaut est $wgMainCacheType, avec un repli vers MySQL).



Texte des révisions

 * Accédé via.
 * Enregistré dans le cache WAN en utilisant la classe de clés.
 * Les clés sont vérifiables et les valeurs ne sont pas mutables. Le cache est rempli sur demande.

Contexte
Le cas d'utilisation principal de la mise en cache du texte de la version (par opposition à la recherche directe dans la table ou le Stockage externe) sert à gérer les cas où le texte de nombreuses pages différentes est nécessaire pour une seule requête web.
 * Implémenté initialement en 2006 (, commit 376014e).
 * Cache des processus ajouté en 2016.
 * Adopté par MessageCache en 2017.

Utilisé initialement par :


 * L'analyse syntaxique du wikicode. Lors de l'analyse syntaxique d'une page wiki donnée, l'analyseur (Parser) a besoin du source de la page courante, mais également et d'une manière récursive, du source de chacune des pages des modèles transclus (ainsi que des pages des modules Lua). Il n'est pas rare qu'un article populaire transclue plus de 300 telles pages. L'utilisation de Memcached permet de gagner du temps lors de la sauvegarde des modifications et de la génération de l'affichage des pages.
 * MessageCache. Ceci est une couche spécifique au wiki qui vient au-dessus du LocalisationCache et qui consiste principalement en la réécriture des messages à partir des pages de l'espace de noms « MediaWiki: » du wiki considéré. Lors de la construction de ce blob, il faut récupérer le texte source des différentes pages. Ceci est mis en cache en fonction de chaque grappe dans Memcached et localement par serveur (afin de réduire la bande passante de Memcached;, commit 6d82fa2).

Exemple
Clé.

content address fait référence à  de la base de données principale du wiki (par exemple tt:1123). A son tour, cela s'adresse à la table ou au (Stockage externe).

Pour faire le reverse engineering et trouver à quelle page ou révision cela correspond, faites un Find de  pour l'adresse de contenu, puis recherchez l'ID de révision pour cet emplacement de contenu.

L'ID de révision peut alors être utilisé sur le wiki dans une URL telle que https://en.wikipedia.org/w/index.php?oldid=951705319, ou vous pouvez le rechercher dans les tables des révisions et des pages.



Métadonnées des révisions

 * Accédé via.
 * Stocké dans le cache WAN en utilisant les clés de classe.
 * Les clés sont vérifiables (par page et par ID de révision) et les valeurs sont non mutables. Le cache est rempli sur demande.

MessageBlobStore
Enregistre le texte d'interface utilisé par les modules du ResourceLoader. Il est similaire au LocalisationCache, mais comprend les réécritures spécifiques au wiki. (LocalisationCache est indépendant du wiki). Ces réécritures viennent de la base de données et des pages wiki de l'espace de noms MediaWiki.


 * Accédé via.
 * Enregistré dans le cache WAN en utilisant la classe de clés.
 * Les clés sont vérifiables (à l'aide du nom du module ResourceLoader et du hachage des clés de messages). Les valeurs sont mutables et expirent après une semaine. Le cache est rempli sur demande.
 * Toutes les clés sont purgées quand on reconstruit  LocalisationCache. Quand un utilisateur enregistre une modification sur une page de l'espace de noms MediaWiki du wiki, un sous-ensemble des clés est également purgé.



Cache des vignettes
ResourceLoader met en cache les versions réduites des fichiers d'entrée bruts JavaScript et CSS.
 * Accédé via.
 * Enregistré localement sur le serveur (APCu).
 * Les clés sont vérifiables (valeur déterministe). Pas de stratégie nécessaire pour purger. Le cache est rempli sur demande.



Cache des compilations LESS
ResourceLoader met en cache les métadonnées ainsi que les sorties de l'analyseur syntaxique des fichiers LESS qu'il a compilés.


 * Accédé via.
 * Enregistré localement sur le serveur (APCu).



Hachage de l'entête du contenu des fichiers
ResourceLoader met en cache la somme de contrôle (checksum) de chaque fichier utilisé directement ou indirectement par un module. Lorsque le manifest de démarrge est distribué aux utilisateurs, les codes de hachage de plusieurs milliers de fichiers sont nécessaires. Afin de réduire la surcharge des entrées-sorties le contenu de ces hachages est placé dans le cache local et accédé via une clé formée à partir du chemin et de mtime.


 * Accédé via.
 * Enregistré localement sur le serveur (APCu).



Voir aussi

 * Modules d'architecture : le cache
 * Réglage des performances : comment configurer votre serveur web et / ou le proxy du cache et MediaWiki; afin d'améliorer les performances.
 * Cache des fichiers: mécanisme de cache simplifié qui mémorise sur disque les réponses HTTP.
 * Paramétrisation du cache : différents paramètres de configuration des caches des bases arrière et pour en autoriser l'utilisation par l'application.
 * , bibliothèque fournissant cette fonctionnalité