Manual:Maxlag parameter/ja

(Wikimediaのように)複製データベースクラスター上でMediaWikiを稼働させている場合、 高い編集率によってスレイブサーバが遅延することがあります. スレイブの遅延を和らげる一つの方法は遅延がある値を超えたときはすべてのボットとメンテナンスタスクを自動的に停止させることです. サーバーサイドスクリプトにおいて、これはwfWailForSlavesを使用することで行われます. MediaWiki 1.10において、導入されたmaxlagパラメータはクライアントサイドで同じことを行うことを可能にします.

maxlagパラメータはURLパラメータ、POSTデータもしくはクッキーを通してindedx.phpに渡すことが出来ます. これは整数の秒数です. 例えばこのリンクは遅延が1秒以上でなければこのページを編集します.

指定された遅延がリクエストの時点で越えている場合、次のフォーマットを持ったリスポンスボディと一緒に503ステータスコードが返されます:


 * Waiting for $host: $lag seconds lagged\n

次のようなHTTPヘッダーが設定されます:


 * Content-Type: text/plain
 * Retry-After: リトライをする前にクライアントが待つ推奨の最小秒数.
 * X-Database-Lag: もっとも遅延したスレーブの遅延秒数

Wikimediaのwiki群に対する推奨される使い方は次の通りです:


 * maxlag=5(5秒)を使います. Mediawikiの多くのサーバサイドにスクリプトで使用される適切で活動的ではない値です、より高い値はより活動的な振る舞いを意味し、低い値はより快適であることを意味します.
 * 遅延エラーを受け取る場合、再び試す前に少なくとも5秒間はスクリプトを停止させて下さい. ビジーループに陥らないように注意して下さい.
 * この値によって、高いデータベースロードの時に低いデューティサイクルを得る可能性があります. それはOKで、オフピークを待って下さい. 編集を拒否することでユーザーの時間を無駄にしたくないので高いロードの時は人間を優先します.
 * 普通ではない高いもしくは持続する遅延はirc.freenote.net上の#wikimedia-techに報告されます.

アップストリームサーバのタイムアウトが原因で、Squidが503ステータスコードを持つエラーメッセージを生成することもあります. クライアントはこれらのエラー別々に取り扱います. 長期の負荷のかかるオペレーションを実行しようとするときにそれらが連続的に起こるかもしれないからですタイムアウトを起こすオペレーションを繰り返すことで過度のサーバリソースを使用してクライアントを無限ループに陥らせることがあります. 次の内容によってsquidエラーとMediaWikiの遅延条件を区別出来ます:


 * X-Database-Lag header is distinctive to slave lag errors in MediaWiki
 * squildエラーではRetry-Afterは存在しません
 * X-Squid-Errorヘッダーはsquidエラーで表示されます
 * スレーブ遅延エラーでのリスポンスボディは正規表現の /Waiting for [^ ]*: [0-9.-]+ seconds lagged/ にマッチします

テストの目的のために、負の値を渡すことで故意にソフトウェアにリクエストを拒否さ競ることが出来ます. 例えば次のURLです:

maxlagパラメータはindex.phpで確認出来ます.