Manuel:Cache de l'analyseur syntaxique

This page is a translated version of the page Manual:Parser cache and the translation is 47% 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 la File d'attente des tâches 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. One example for this is the FlaggedRevs extension which uses a separate ParserCache to store the rendered output of the "stable" revision of each page, rather than the current revision. Another example is migration to a different parser (such as Parsoid ), which makes it necessary for a while to have caches for the output of the new as well as of the old parser.

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. Like ParserCache, it supports varying keys based on options, but it uses a simpler system since it is not designed for long term persistence.

The intent of this cache is to protect against load spikes caused by certain old revisions being viewed by a large number of users, typically due to an external "deep" link to that revision.

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

Métadonnées et données de payload

The primary content of the parser cache is rendered output (HTML) generated from the page content (typically wikitext). 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).
  • Derived data: this includes information about links and dependencies, e.g. which pages does the output link to, which templates were used in its creation, which images are included on the page. This also includes any special scripts or style sheets required to display the page, as well as arbitrary "page properties" that are to be placed in the page_props table.
  • 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(). Earlier versions of MediaWiki relied on PHP's built-in serialization mechanism and allowed for arbitrary objects to be stored, at the cost of robustness and security (see phab:T161647).

See Manual:Parser cache/Serialization compatibility for more information on payload serialization.

Structure du cache et espace des clés

The ParserCache class supports storing multiple ParserOutput objects for each page, based on the ParserOptions used when generating the output. To avoid duplicating cache entries by varying the cache key on options that were not actually used, a two-tiered system is employed:

The first tier is keyed by the page ID and stores a CacheTime object, which contains information about cache expiration and the list of options used during the parse of the page. For example, if only the dateformat and userlang options were accessed by the parser when producing output for the page, this fact will be stored in the metadata cache.

The second tier of the cache contains the actual ParserOutput objects. The key for the second tier is constructed from the page ID and values of any options that affected the output. Upon cache lookup, the list of used option names is retrieved from the first tier, and only the values of those options are used together with the page ID to produce a key, while the rest of the options are ignored. Following the example above where only the dateformat and userlang options affected the output for the page, the key may look something like page_id!dateformat=default:userlang=ru. Thus any cache lookup with dateformat=default and userlang=ru will hit the same cache entry regardless of the values of the rest of the options, since we know from the information in the first cache tier that they did not affect the output.

The RevisionOutputCache also varies cache keys based on parser options, but always considers all options. This simplifies the system and speeds up access, but may lead to fragmentation. This is acceptable since RevisionOutputCache entries generally have a low expiry time, making a large number of variants unlikely.

Population, Invalidation, Expiry, and Eviction

The main ParserCache instance serves as a semi-permanent store of a wiki's content as seen by readers. The default ("canonical") rendering of the page is generated immediately when the page is edited, or when any template or other dependency of the output changes (see LinksUpdate ). Output using different options is generated and cached on demand.

ParserCache uses a passive invalidation model based on timestamps: When the content of a page changes, a timestamp is updated in the database (specifically, the page_touched field in the page table). If a cached ParserOutput object is found to be older than this timestamp, it is considered outdated (dirty). Outdated content may still be served to the user depending on context.

In addition to invalidation, entries in a ParserCache will expire after a set period (see Manuel:$wgParserCacheExpireTime ). The expiry time can be lowered on a per-page basis, depending on the content of the page by calling updateCacheExpiry() on the ParserOutput object. Extensions that allow the inclusion of dynamic content may use this to ensure that the dynamic content is re-evaluated at an appropriate rate. Beyond this, the Manuel:$wgCacheEpoch setting provides a way to expire all cache entries older than a specific point in time, e.g. to ensure that changes in the site's setup or configuration take effect.

Depending on the configuration of the cache's storage backend (see Manuel:$wgParserCacheType ), cache entries may or may not be evicted from the cache prior to expiry, or may or may not be pruned from storage once expired. In general, the parser cache should be configured to ensure a very good hit rate, since it directly affects the time it takes to load a page for reading.

For information about the setup of the parser cache backend for Wikimedia sites, see wikitech:Parser cache.

The RevisionOutputCache in contrast is much simpler: it is populated opportunistically when renderings become available, and stores data in the Manual:Object cache#WAN cache using a relatively short expiry time (see Manuel:$wgOldRevisionParserCacheExpireTime ). Low hit rates are expected under normal operations, since it is generally rare for the same old revision to be visited a lot in a short time span.

Configuration

Voir aussi