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 de statut 503 est renvoyé (ou 200 lors des requêtes à l’API, voirT33156), avec une 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ée par défaut pour Pywikibot. Des valeurs plus élevées induisent 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. Prenez soin de ne pas entrer dans une boucle d’occupation infinie.
 * Il est possible qu’avec cette valeur vous obteniez un court délai d’attente lorsque la base de données subit une forte activité. C’est normal, laissez la simplement requête attendre une baisse d’activité. En période de forte activité, nous donnons la priorité aux humains parce que nous ne voulons pas faire perdre leur temps en rejetant leurs modifications.
 * Un délai de ralentissement inhabituellement élevé ou persistant devrait être signalé sur irc.freenode.net.

Notez qu’un serveur frontal de cache (Varnish ou squid) peut également générer des messages d’erreur avec un code de statut 503, à cause du dépassement de leur délai maximal d’attente d’un serveur en amont. Les clients devraient traiter ces erreurs différemment, parce qu’elles peuvent survenir de façon systématique lorsque vous tentez une opération intensive longue à exécuter. La répétition automatique de l’opération suite à un dépassement de délai provoquerait un usage excessif du serveur et pourrait conduire votre client à entrer dans une boucle d’attente infinie. Vous pouvez distinguer les erreurs provenant d’un frontal de cache et les conditions normales de ralentissement de MediaWiki en utilisant un des moyens suivants :


 * l’en-tête X-Database-Lag: est distinctif des erreurs d’attente des esclaves dans MediaWiki ;
 * l’en-tête Retry-After: est absent dans les erreurs provenant d’un frontal Varnish ;
 * l’en-tête X-Squid-Error: devrait être présent dans les erreurs provenant d’un frontal squid ;
 * le corps de la réponse dans les messages d’erreur provenant d’un serveur esclave devrait correspondre à l’expression régulière  .

Afin d’effectuer des tests, vous pouvez intentionnellement faire en sorte que le logiciel refuse d’exécuter une requête en passant une valeur négative, comme dans l’URL suivante : [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 /w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1].

Le paramètre maxlag</tt> est pris en compte aussi bien par Wiki.php que par l’API action.