Object cache/fr

MediaWiki utilise la mise en cache pour beaucoup 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 si la valeur n'est pas obsolète.

Ceci ne s'applique que si une clé ne possède une valeur unique, comme le calcul du 100e chiffre de Pi, peut être mis en cache avec la clé. Le résultat peut être rangé de manière sécurisée sur 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 la même chose pour enregistrer le wikicode d'une révision de page donnée. 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 des primitives (booléens, entiers, chaînes) et les structures des tableaux (éventuellement imbriquées). 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 des anciennes versions et des nouvelles de manière concurrente.
 * 2) Les opérateurs des sites doivent pouvoir restituer le dernier déploiement ou remettre à jour avec le logiciel de la précédente version.

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 pour ceci 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ée 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

 * 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és 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 en initialisant la clé directement).

Voir aussi WANObjectCache sur wikitech.wikimedia.org.



Zone de réserve principale

 * 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 stockées et centralisées dans le centre de données primaire, puis répliquées ultérieurement sur les autres centres de données. Utilise typiquement MySQL et Redis comme base arrière. Par défaut la table est utilisée. Les clés sont en général lues à partir d'un réplicat local et peuvent donc présenter une certaine latence. Les lectures dans la base de données primaire peuvent être faites en utilisant, mais ne doivent pas se produire pendant les requêtes GET.

This store is expected to have strong persistence and is often used for data that cannot be regenerated and is not stored elsewhere. However the data stored here must be non-critical and result in minimal user impact if lost, thus allowing for the backend to sometimes be partially unavailable or wiped if under operational pressure without causing 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.
 * Backend configured by (typically MySQL).
 * Keys are canonical by page ID and populated when a page is parsed.
 * L'ID de révision est vérifié lors la récupération.



Cache des messages

 * Accès via.
 * Backend configurable by $wgMessageCacheType (defaults to $wgMainCacheType, with fallback to 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
The main use case for caching revision text (as opposed to fetching directly from the  table or External Storage) is for handling cases where the text of many different pages is needed by a single web request.
 * Implémenté initialement en 2006 ((, commit 376014e).
 * Cache des processus ajouté en 2016.
 * Adopté par MessageCache en 2017.

Utilisé initialement par :


 * Parsing wikitext. When parsing a given wiki page, the Parser needs the source of the current page, but also recursively needs the source of all transcluded template pages (and Lua module pages). It is not unusual for a popular article to indirectly transclude over 300 such pages. The use of Memcached saves time when saving edits and rendering page views.
 * MessageCache. This is a wiki-specific layer on top of LocalisationCache, which consists primarily of message overrides from "MediaWiki:"-namespace pages on the given wiki. When building this blob, the source text of many different pages needs to be fetched. This is cached per-cluster in Memcached, and locally per-server (to reduce Memcached bandwidth ;, commit 6d82fa2).

Exemple
Clé.

"content address" refers to the  on the wiki's main database (e.g. "tt:1123"). This in turn refers to the table or (External Storage).

To reverse engineer which page/revision this relates to, Find  for the content address, then find the revision ID for that content slot ,

The revision ID can then be used on-wiki in a url like https://en.wikipedia.org/w/index.php?oldid=951705319, or you can look it up in the revision and page tables.



Métadonnées des révisions

 * Accessed via.
 * Stored in the WAN cache, using key class.
 * Keys are verifiable (by page and revision ID) and values immutable. Cache is populated on demand.

MessageBlobStore
Stores interface text used by ResourceLoader modules. It is similar to LocalisationCache, but includes the wiki-specific overrides. (LocalisationCache is wiki-agnostic). These overrides come from the database as wiki pages in the MediaWiki-namespace.


 * Accessed via.
 * Stored in the WAN cache, using key class.
 * Keys are verifiable (by ResourceLoader module name and hash of message keys). Values are mutable and expire after a week. Cache populated on demand.
 * All keys are purged when LocalisationCache is rebuild. When a user save a change to a MediaWiki-namespace page on the wiki, a subset of the keys are also purged.



Cache des vignettes
ResourceLoader caches the minified versions of raw JavaScript and CSS input files.
 * Accessed via.
 * Stored locally on the server (APCu).
 * Keys are verifiable (deterministic value). No purge strategy needed. Cache populated on demand.



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.


 * Accessed via.
 * Stored locally on the server (APCu).



Hachage de l'entête du contenu des fichiers
ResourceLoader caches the checksum of any file directly or indirectly used by a module. When serving the startup manifest to users, it needs the hashes of many thousands of files. To reduce I/O overhead, it caches this content hash locally, keyed by path and mtime.


 * Accessed via.
 * Stored locally on the server (APCu).



Voir aussi

 * Architectural modules/Cache
 * Manual:Performance tuning: How to configure your web server and/or cache proxy and MediaWiki; to improve performance.
 * Manual:File cache: Simplistic cache mechanism that caches HTTP responses on-disk.
 * Manual:Configuration settings: Various configuration settings to set up caching backends and enable parts of the application to use them.