Manual:Maxlag parameter/fr

Si vous utilisez MediaWiki sur un cluster de base de données répliquée (tout comme Wikimedia), alors un taux de modifications élevé peut se traduire par des ralentissements sur les serveurs esclaves. Un moyen de limiter le ralentissement de l'esclave est d'avoir tous les bots et toutes les tâches de maintenance qui s'arrêtent automatiquement si le ralentissement dépasse une certaine valeur. Dans MediaWiki 1.10, le paramètre maxlag a été introduit. Il permet que la même chose soit faite dans des scripts du côté client. Dans 1.27, il a été mise à jour pour ne fonctionner que pour les requêtes.

Le paramètre maxlag peut être passé à api.php via un paramètre d'URL ou une donnée POST. Il s'agit d'un nombre entier de secondes. Par exemple, [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=1 ce lien] montre des métadonnées sur la page « MediaWiki » à moins que le ralentissement soit supérieur à 1 seconde tandis que [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 celui-là] (avec -1 à la fin) vous montre le ralentissement actuel sans métadonnées..

Si le ralentissement indiqué excède le temps de la requête, un code 503 est renvoyé (ou 200 pendant des requêtes API, voirT33156), avec un réponse qui suit le format suivant :

Les en-têtes HTTP suivants sont réglés :


 * Retry-After : un nombre minimum de secondes recommandé que le client doit attendre avec de réessayer
 * X-Database-Lag : le nombre de secondes de ralentissement de l'esclave le plus ralenti

Un usage recommandé pour les wikis de Wikimedia est le suivant :


 * Utiliser maxlag=5 (5 secondes). Il s'agit d'une valeur appropriée non-agressive, réglé par défaut pour Pywikibot. Des valeurs plus grandes signifie un comportement plus agressif, des valeurs plus faibles sont plus sympas.
 * Si vous obtenez une erreur de ralentissement, mettez en pause votre script pour au moins 5 secondes avant de réessayer. Soyez attentif de ne pas entrer dans une boucle sans cesse occupée.
 * It's possible that with this value, you may get a low duty cycle at times of high database load. That's OK, just let it wait for off-peak. We give humans priority at times of high load because we don't want to waste their time by rejecting their edits.
 * Unusually high or persistent lag should be reported to on irc.freenode.net.

Note that the caching layer (Varnish or squid) may also generate error messages with a 503 status code, due to timeout of an upstream server. Clients should treat these errors differently, because they may occur consistently when you try to perform a long-running expensive operation. Repeating the operation on timeout would use excessive server resources and may leave your client in an infinite loop. You can distinguish between cache-layer errors and MediaWiki lag conditions using any of the following:


 * X-Database-Lag header is distinctive to slave lag errors in MediaWiki
 * No Retry-After in Varnish errors
 * X-Squid-Error header should be present in squid errors
 * The response body in slave lag errors will match the regex

For testing purposes, you may intentionally make the software refuse a request by passing a negative value, such as in the following URL: [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 /w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1].

The maxlag parameter is checked in Wiki.php, and also applies to the action API.