Jump to content

Manuel:Cache de l'analyseur syntaxique

From mediawiki.org
This page is a translated version of the page Manual:Parser cache and the translation is 97% complete.
Outdated translations are marked like this.

Le cache de l'analyseur syntaxique sert de cache aux sorties des pages wiki générées. C'est le service de cache primaire pour fournir les pages affichées de MediaWiki (sans prendre en compte un quelconque cache web comme Varnish devant MediaWiki). Le cache principal ParserCache contient la sortie de la dernière version des pages.

Terminologie

Certains termes relatifs à la documentation sur cette page :

  • rendered output ou simplement output est le HTML à afficher et généré à partir du contenu d'une page wiki, avec des données supplémentaires pouvant lui être attachées. Dans lecas de wikicode, la sortie est générée par l'analyse sytntaxique, mais d'autres types de pages peuvent utiliser d'autres mécanismes pour générer la sortie (qui est le rendu du contenu de la page) via un gestionnaire de contenu (ContentHandler). En plus du contenu de la page lui-même, la sortie peut dépendre d'autres ressources, principalement des modèles.
  • options peut être utilisé pour modifier la sortie générée d'une page en fonction des préférences utilisateur ou du contexte dans lequel la sortie est utilisée.
  • varying concerne différentes clés du cache basées sur les options (certaines), qui permettent que plusieurs entrées de cache (les variants) co-existent pour une même page et révision. Les clés varying segmentent le cache et peuvent alors conduire à une fragmentation indésirable qui va grignoter progressivement les capacités du cache.
  • invalidation se rapporte au processus de marquage d'une entrée obsolète du cache (sale). Une entrée dans le cache de l'analyseur syntaxique devient non valide lorsque le contenu de la page a changé. Lorsque les resources dont la page dépend sont modifiées, l'entrée du cache sera invalidée de manière asynchrone (voir File d’attente des travaux pour d'autres informations sur ce mécanisme).
  • expiry se produit lorsqu'une entrée du cache a dépassé une limite d'âge prédéfinie. L'age maximum peut être défini pour l'ensemble du cache ou pour chaque entrée individuellement, ou encore pour les deux à la fois.
  • eviction concerne la suppression des entrées du cache pour faire de la place à de nouvelles entrées (voir les politiques de remplacement du cache sur Wikipedia).
  • pruning est l'action de supprimer du cache les entrées qui ont expiré afin de libérer de la capacité

Types

Il existe deux types de caches pour la sortie des pages générées.

ParserCache

La classe ParserCache met en cache la sortie générée (HTML et ses données associées) de la dernière révision d'une page. Il sert de dépôt semi-permanent du contenu actuel du wiki tel que vu par les lecteurs. ParserCache accepte différentes clés en fonction des options et utilise un système à deux niveaux pour éviter la fragmentation inutile du cache.

Depuis MediaWiki 1.36, il est possible d'avoir plusieurs instances ParserCache en parallèle. Cela peut être utilisé dans les situations où des sortes entièrement différentes de sorties doivent être stockées pour chaque page, ou que la sortie dépende de facteurs au-delà de ce qui est couvert par ParserOptions. Un exemple de cela est l'extension FlaggedRevs qui utilise un ParserCache séparé pour stocker la sortie rendue de la version stable de chaque page, plutôt que celle de la version actuelle. Un autre exemple est la migration vers un analyseur syntaxique différent (tel que Parsoid ), ce qui rend nécessaire pendant un certain temps d'avoir des caches pour la sortie du nouvel analyseur ainsi que pour celle de l'ancien.

Différentes instances ParserCache sont gérées par la ParserCacheFactory qui peut être obtenue de MediaWikiServices.

RevisionOutputCache

Version de MediaWiki :
1.36

La classe RevisionOutputCache , introduite dans MediaWiki v1.36, implémente le cache pour la sortie générée des anciennes versions d'une page. Comme ParserCache, il prend en charge différentes clés basées sur les options, mais il utilise un système plus simple car il n'est pas conçu pour une persistance à long terme.

L'intention de ce cache est de protéger contre les pics de charge causés par certaines anciennes révisions vues par un grand nombre d'utilisateurs, généralement en raison d'un lien profonde externe sur cette révision.

Comme pour ParserCache, les instances de RevisionOutputCache sont gérées par ParserCacheFactory .

Métadonnées et données du contenu

Le contenu principal du cache de l'analyseur est la sortie rendue (le HTML) générée à partir du contenu de la page (typiquement le wikicode). De plus, le ParserOutput du cache contient les types suivants d'informations :

  • Métadonnées du cache : cela comprend les informations sur la version pour laquelle la sortie a été générée, l'horodatage de la génération, et sa durée de validité. De plus, ParserOutput enregistre les options utilisées pour la génération de la sortie (c'est à dire les options desquelles dépend la sortie).
  • Données dérivées : ceci comprend les informations concernant les liens et les dépendances, par exemple quelles pages pointent vers, quel modèles ont été utilisés à la création, quelles images sont sur la page. Cela comprend également les scripts spéciaux ou les feuilles de style nécessaires pour afficher la page ainsi que les propriétés de page arbitraires qui doivent être reportées dans la table page_props .
  • Données d'extension : les extensions peuvent attacher des données arbitraires à l'objet ParserOutput et qui seront mises en cache en même temps que la sortie générée. Ceci permet aux extensions de passer des informations à partir du code exécuté pendant l'analyse syntaxique, au code exécuté à l'affichage de la page lors d'une requête ultérieure.

Depuis MediaWiki v1.36, les données stockées dans le cache de l'analyseur syntaxique sont encodées en JSON. Pour cette raison, seules des données primaires et les objets qui implémentent l'interface JsonUnserializable peuvent être stockés dans le cache en utilisant setExtensionData(). Les versions précédentes de MediaWiki reposaient sur le mécanisme de sérialisation intégré de PHP et permettaient de stocker des objets arbitraires au prix de la robustesse et de la sécurité (voir phab:T161647).

Dans MediaWiki 1.45, la sérialisation et la désérialisation PHP ont été supprimées, et seul l'encodage JSON est pris en charge (voir phab:T353570).

Voir la compatibilité de la sérialisation pour d'autres informations sur la sérialisation du contenu.

Structure du cache et espace des clés

La classe ParserCache prend en charge le stockage de plusieurs objets ParserOutput pour chaque page, en fonction des ParserOptions utilisés lors de la génération de la sortie. Pour éviter de dupliquer les entrées de cache en modifiant la clé de cache sur les options qui n'ont pas été réellement utilisées, un système à deux niveaux est utilisé :

Le premier niveau a pour clé l'ID de la page et stocke un objet de CacheTime, qui contient des informations sur l'expiration du cache et la liste des options utilisées lors de l'analyse de la page. Par exemple, si l'analyseur n'a accédé qu'aux options dateformat et userlang lors de la génération de la sortie de la page, ce fait sera stocké dans le cache des métadonnées.

Le second niveau du cache contient les objets ParserOutput actuels.

  • La clé du deuxième niveau est construite à partir de l'ID de la page et des valeurs des options qui ont affecté la sortie. (ParserCache::makeParserOutputKey)
  • Lors de la recherche dans le cache, la liste des noms des options utilisées est récupérée à partir du premier niveau, et seules les valeurs de ces options sont utilisées avec l'ID de page pour produire une clé, tandis que le reste des options est ignoré. (ParserOptions::optionsHash)

If none of the options differs from the default, the options hash will be set to canonical. Suite à l'exemple ci-dessus où seules les options dateformat and userlang ont modifié la sortie de la page, la clé peut ressembler au page_id!dateformat=default:userlang=ru. Ainsi, toute recherche dans le cache avec dateformat=default et userlang=ru atteindra la même entrée du cache indépendamment des valeurs du reste des options, puisque nous savons à partir des informations dans le premier niveau de cache qu'ils n'ont pas affecté la sortie.

RevisionOutputCache modifie également les clés du cache en fonction des options de l'analyseur, mais prend toujours en compte l'ensemble des options. Cela simplifie le système et accélère l'accès, mais peut conduire à la fragmentation. Cela est acceptable puisque les entrées RevisionOutputCache ont généralement un temps d'expiration faible, ce qui rend un grand nombre de variantes peu probable.

Peuplement, invalidation, péremption, et suppression

L'instance principale ParserCache sert de dépôt semi-permanent pour le contenu du wiki tel qu'il est vu par les lecteurs. La version générée par défaut (canonique) de la page est fournie immédiatement dès que la page est modifiée, ou lorsque tout modèle ou autre dépendance de la sortie change (voir l'accroche LinksUpdate ). Les sorties utilisant différentes options sont générées et mises en cache à la demande.

ParserCache utilise un modèle d'invalidation passive basé sur l'horodatage : When the content of a page changes, a timestamp is updated in the database (specifically, the page_touched field in the page table). Si un objet ParserOutput dans la cache est plus ancien que cet horodatage, il est considéré comme obsolète (sale). Le contenu obsolète peut encore être fourni à l'utilisateur selon le contexte.

In addition the the ordinary invalidation mechanisms, the RejectParserCacheValue hook allows arbitrary invalidation of entries that would otherwise hit in the cache. This is typically used to rollback bad entries created by a software bug of some sort. See the Incident Response section below.

En plus de l'invalidation, les entrées dans ParserCache expireront après une période déterminée (voir Manuel:$wgParserCacheExpireTime ). Le délai d'expiration peut être réduit par page, en fonction du contenu de la page en appelant updateCacheExpiry() sur l'objet ParserOutput. Les extensions permettant l'inclusion de contenus dynamiques peuvent utiliser cela pour s'assurer que le contenu dynamique est réévalué à une fréquence appropriée. En plus de cela, la définition de Manuel:$wgCacheEpoch offre un moyen de mettre fin à toutes les entrées de cache plus anciennes qu'un point spécifique dans le temps, par exemple pour s'assurer que les changements dans les paramètres ou la configuration du site prennent effet.

Selon la configuration du serveur du dépôt du cache (voir Manuel:$wgParserCacheType ), les entrées du cache peuvent (ou non) être purgées avant leur expiration, ou peuvent (ou non) être supprimées du dépôt une fois expirées. En général, le cache de l'analyseur doit être configuré pour assurer un très bon taux de reconnaissance, car cela affecte directement le temps nécessaire pour charger une page à lire.

Pour les informations concernant la configuration du serveur du cache de l'analyseur pour les sites Wikimedia, voir Parser cache sur Wikitech.

Au contraire RevisionOutputCache est beaucoup plus simple : it est rempli occasionnellement dès que les rendus sont disponibles et stocke les données dans le cache WAN en utilisant un temps de péremption relativement court (voir Manuel:$wgOldRevisionParserCacheExpireTime ). Les taux de correspondance sont faibles avec les opérations normales, car il est généralement rare que la même révision ancienne soit fréquemment demandée dans un court laps de temps.

Incident Response

It is difficult to remove entries from the ParserCache. Writes are much more expensive the reads on both of the storage backends for the ParserCache, and the caches have historically operated very close to their maximum write capacity. In almost all cases, content in the cache is allowed to expire (by altering the Manuel:$wgParserCacheExpireTime ) or it is invalidated and overwritten (see below), rather than being deleted.

Similarly, conventional wisdom dictates that the performance impact of a cold cache is dire on a large wiki. As such we generally try to avoid invalidating the entire cache at once, including adhering to a Serialization compatibility policy designed to ensure this for third-party wiki upgrades as well.

If some portion of the cache contents is found to be corrupted, the RejectParserCacheValue hook is used to target specific entries for invalidation. See the documentation on the hook page for examples of its use

Configuration

Voir les paramètres du cache de l'analyseur

Voir aussi