Manual:Maxlag parameter/ru

Если вы используете MediaWiki в реплицированном кластере базы данных (как это делает Wikimedia), то высокая скорость редактирования может привести к задержке подключённых серверов. Один из способов уменьшить отставание подчиненного устройства состоит в том, чтобы все боты и задачи по техническому обслуживанию автоматически останавливались всякий раз, когда отставание превышает определенное значение. В MediaWiki 1.10 был представлен параметр maxlag, который позволяет делать то же самое в клиентских сценариях. В 1.27 он был обновлен, чтобы работать только для запросов.

Параметр maxlag может быть передан в api.php через параметр URL или данные POST. Это целое число секунд. Например, [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=1 this link] показывает метаданные о странице «MediaWiki», если задержка не превышает 1 секунды, в то время как [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 this] (с-1 в конце) показывает фактическую задержку без метаданные.

Если указанная задержка превышена во время запроса, возвращается код состояния 503 (или 200 во время запросов API, см. T33156) с телом ответа в следующем формате:

Установлены следующие HTTP-заголовки:


 * Retry-After: рекомендуемое минимальное количество секунд, которое клиент должен ждать перед повторной попыткой
 * X-Database-Lag: количество секунд отставания работника

Рекомендуемое использование для Wikimedia wikis следующее:


 * Используйте maxlag=5 (5 секунд). Это подходящее неагрессивное значение, установленное в качестве значения по умолчанию для Pywikibot. Более высокие значения означают более агрессивное поведение, более низкие значения лучше.
 * Если вы получаете ошибку задержки, сделайте паузу в вашем скрипте как минимум на 5 секунд, прежде чем пытаться снова. Будьте осторожны, чтобы не войти в занятую петлю.
 * Возможно, что с этим значением вы можете получить низкий коэффициент заполнения в периоды высокой загрузки базы данных. Ничего страшного, просто дайте ему подождать до пика. Мы даем людям приоритет во времена высокой нагрузки, потому что мы не хотим тратить их время, отказываясь от их правок.
 * О необычно высокой или постоянной задержке следует сообщать $irc-канал на irc.freenode.net.
 * Интерактивные задачи (где пользователь ожидает результата) могут не указывать параметр maxlag. Неинтерактивные задачи всегда должны его использовать. См. Также API:Этикет.

Обратите внимание, что уровень кэширования (Varnish или squid) также может генерировать сообщения об ошибках с кодом состояния 503 из-за таймаута вышестоящего сервера. Клиенты должны относиться к этим ошибкам по-разному, поскольку они могут возникать последовательно при попытке выполнить длительную дорогостоящую операцию. Повторение операции по таймауту приведет к чрезмерному использованию ресурсов сервера и может привести к тому, что ваш клиент окажется в бесконечном цикле. 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, and also applies to the action API.