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 une latence sur les serveurs esclaves. Un moyen de limiter le ralentissement de l'esclave est d’avoir tous les robots 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  a été introduit. Il permet que la même chose soit faite dans les scripts du côté client. Dans 1.27, il a été mise à jour pour ne fonctionner qu'avec les requêtes.

Le paramètre  peut être passé à   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 concernant la page « MediaWiki » à moins que la latence soit supérieure à 1 seconde tandis que [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 celui-là] (avec -1 à la fin) vous montre la latence actuelle 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, voir ), avec une réponse dont le corps a 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 avant de réessayer ;
 *   : le nombre de secondes de latence de l’esclave le plus ralenti.

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

See also API:Etiquette#The maxlag parameter.
 * 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 agréables.
 * Si vous obtenez une erreur de latence, 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 requête attendre simplement 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.
 * Une latence inhabituellement élevée ou persistante devrait être signalée sur de irc.freenode.net.
 * Les tâches interactives (où un utilisateur attend le résultat) peuvent omettre le paramètre maxlag . Les tâches non-interactives doivent toujours l'utiliser. Voir aussi API:Etiquette.

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 doivent traiter ces erreurs différemment, parce qu’elles peuvent survenir de façon systématique lorsque vous tentez une opération intensive longue à s'exécuter. La répétition automatique de l’opération suite à un dépassement de délai provoquerait un usage excessif des ressources 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 latence de MediaWiki en utilisant un des moyens suivants :


 * l’en-tête  est distinctif des erreurs de latence des esclaves dans MediaWiki ;
 * l’en-tête  est absent dans les erreurs provenant d’un frontal Varnish ;
 * l’en-tête  devrait être présent dans les erreurs provenant d’un frontal squid ;
 * le corps de la réponse dans les messages d’erreur de latence provenant d’un serveur esclave vérifie 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  est vérifié dans  et s'applique aussi à l’API action.