「2013/11/09-02」の編集履歴(バックアップ)一覧に戻る
2013/11/09-02 - (2013/11/10 (日) 00:30:12) のソース
**ラグ測定結果 その2 連日連夜大盛況が続いている日本国内サーバですが、 残念なことに激しいラグに見舞われています。 21時から24時過ぎにかけて4,000人を越える賑わいを見せていますが、 早いサーバでは2,000人程度から、比較的程度の軽いサーバでも3,000人程度でラグがで始めるようです。 先日はi3D、GS及びシンガポールのアジア圏サーバを比較いたしましたが、 今回はi3Dの3台と海外3台を比較してみました。 ---- ***お問い合わせが多いので、改めて国内サーバにてラグが発生する原因を解説 ***■1.Frostbiteの通信方式 &b(){Frostbite3.0の仕様では、サーバからクライアントに対し&color(red){1秒間に平均20回}の頻度で通信が行われます。} &b(){この通信内容は各プレイヤーの状態に関する情報などが含まれており、&color(red){自分を含む}全プレイヤーの座標(3次元位置情報)も送信されます。} ***■2.いわゆるネットワークコードの基本的な実装 &b(){Frostbiteに限らず一般的なマルチプレイヤーゲームでは下記のようなクライアント側実装方式が採用されています。} &b(){2-1.自分の座標} &b(){ キーボードやマウスからの入力に従い座標計算を行い、画面を描画した後、座標情報をサーバへ送信} &b(){2-2.他のプレイヤーの座標} &b(){ 最後にサーバから受取った座標情報を基準に、移動方向、移動速度及び経過時間などから現在の座標を予測して画面に描画する} &b(){&color(red){2-3.サーバから情報を受信すると}} &b(){ 自分の座標はサーバから送信された情報によって上書き更新されます。} &b(){ これはクライアント側では自分の座標が計算出来ないケースがあるからです。} &b(){ 一例としては、爆風などによりプレイヤーが吹き飛ばされる際、方向や距離に乱数が使用されるケースが挙げられます。} &b(){ この上書き更新の結果、クライアントPCで計算した座標と食い違いが発生すると、} &b(){ サーバ側の情報が優先されるため、強制的にプレイヤーが移動させられます。} &b(){ この現象がいわゆる&color(red){巻き戻り}と呼ばれています。} &b(){ 他のプレイヤーの座標はクライアントPCにて予測で算出しており、常に誤差が生じるため、} &b(){ こちらもサーバから送信された情報によって頻繁に訂正されています。} &b(){ しかし、この訂正される程度が大きくなると、他のプレイヤーの座標が訂正されたことが目視確認出来ます。} &b(){ この現象がいわゆる&color(red){ショートワープ}などと呼ばれています。} ***■3.なぜサーバから送信される情報が大きく狂うのか? &b(){これは簡単なお話です。} &b(){3-1.サーバへ送信した自分の座標情報をサーバが受け取れなかったから} &b(){3-2.サーバからクライアントへ情報を送信出来なかったから} &b(){3-3.サーバから送信された情報がクライアントまで届かなかったから} &b(){3-4.サーバから送信された情報が古かったから} &b(){&color(red){一般的に3-1.及び3-2.はサーバの高負荷によって発生する事象、}} &b(){&color(red){3-3及び3-4はネットワークの高負荷によって発生する事象。}} &b(){※但し、ネットワークの高負荷は状況的に考えられないため、詳細な解説は割愛致します。} ***■4.なぜサーバは受取れなかったり送信出来なかったりするのか? &b(){これも簡単なお話です。 &b(){要求された性能を満たせないサーバが使われているから。} &b(){プレイヤー数が少ない時間帯であれば処理しきれるためラグが発生することは稀なようですが、} &b(){プレイヤー数の多い時間帯になると処理しきれない残念なサーバが使われています。} &b(){これだけのお話ですが、致命的なお話です。} ---- ***解説が長くなりましたがゲームサーバのモニタリング結果です &b(){クライアントPCから送信した情報をサーバが受取れているかは、クライアントPCから見えないためわかりません。} &b(){(これはTCP/IPではない低信頼性の通信方式が使用されていることに起因します)} &b(){しかし、サーバからクライアントに情報が送信されているか否かは、} &b(){クライアントPCが1秒間に受信した回数を測定すれば一目瞭然です。} &b(){そこで実際のプレイ中にクライアントPCが受信した1秒あたりの回数を測定致しました。 ---- ***■測定前提 &b(){ ・測定日時 : 2013/11/09 21:30頃から22:30頃まで} &b(){ ・測定サーバ : 日本国内 i3Dにて稼働している 3台及び} &b(){ シンガポール、オーストラリア、アメリカ(西海岸)にて稼働している3台の合計6台} &b(){ ・プレイヤー数 : 64スロット機がほぼ満員の状態にて測定} &b(){いつも通りの超手抜きグラフ (縦軸は1秒あたりの受信回数)} &image(Lag_20131109.png) ---- &b(){海外のサーバに接続しているケースでは、ほぼ毎秒20回のペースを維持しているのに対し、} &b(){i3Dの3台は毎秒15回程度に留まっています。} &b(){そのため、&color(red){1秒間に5回ものペースで自分の位置情報が}} &b(){&color(red){古いデータに変更されている可能性があることを意味します。}} &b(){20回に5回の割合でデータが失われていることになりますが、} &b(){この5回がどのような形で発生するかで体感的には大きく異なります。} &b(){○ 受信成功} &b(){● 受信失敗} &b(){(例.1)} &b(){○○○○●○○○○●○○○○●○○○○●} &b(){このようなケースでは座標が修正される程度が小さいのでほとんど体感出来ないと思います。} &b(){(例.2)} &b(){○○○○○○○○○○○●●●●○○○○○} &b(){しかし、このケースでは連続で4回分も情報が失われており、} &b(){単純計算で0.2秒も前の状態に戻されてしまうため、体感的な問題につながります。} ---- &b(){実際には(例.2)のもっと酷い状態に陥っていると考えられ、} &b(){1回ごとの情報到着間隔を精密に測定すれば詳細が判明しますが、} &b(){規定通りにサーバから情報が送信されていないことは確実であり、} &b(){RSP(ゲームサーバを貸している会社)には改善を期待致します。} &b(){尚、本件は珍しくEAとは無関係に発生している問題です。} &b(){(このような企業をRSPに認定していることが問題かもしれませんが) (&Counter())