ゲームラグ白書 › L1 クライアントのゲームプロセス
メインスレッドのパケット処理ボトルネック Network processing on the main thread
原因ID cg-net-mainthread · 主担当 ゲーム開発チーム・クライアント開発 · 副担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
受信したパケットをフレームごとに決まった量しか処理しないと、押し寄せたパケットがどんどん次のフレームへ持ち越されます。
なぜ 人が多い場所で、毎秒数千件の更新が届く → すると メインスレッドがフレームあたりの処理量の上限に達し、読み切れない → 画面では 他の人の動きがだんだん遅れ、まとめて反映される
- 症状
- 早送り, 入力遅延
- 要因
- ストール, 遅延
- 誰に起きるか
- 特定の場所・チャンネル, 自分だけ
- いつ
- 人が集中したとき
- 担当
- 主担当 ゲーム開発チーム・クライアント開発 · 副担当 ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- クライアント：受信・解析は別スレッドで行い、同じ対象の古い位置更新はまとめて最新のものだけを適用。サーバー：人が多い場所では遠くのキャラクターの更新を送る頻度を下げて送信量を削減。
- 数値の目安
- 処理しきれないパケットがたまると、数秒で1秒分の遅れになります。
- グラフでは
- 人数・負荷に連動して上昇 · 未処理の受信パケット数、受信〜適用の遅延
- 確認箇所
- クライアントがフレームごとに処理しきれず残したパケット数と、パケットの到着からゲームに適用するまでの遅延をログに記録し、周囲の人数とあわせて確認
- 該当する場合
- 人が多い場所で、残ったパケット数と適用までの遅延が増え続け、同じ時刻のPingとサーバーの送信間隔は正常
- 該当しない場合
- 適用までの遅延はないのにパケット自体の到着が遅いならネットワーク区間。フレームタイムが大きく上がるなら「大人数の描画負荷」
- 確認手段
- ゲームサーバー・クライアントのログ・メトリクスが必要
出典
- Actor Priority in Unreal Engine Epic Games
帯域幅が足りないときはすべてのアクターを毎回レプリケートせず、見ている人との距離や最後のレプリケーションからの経過時間で優先度を付ける - Replication Graph in Unreal Engine Epic Games
接続者やレプリケーション対象が多いゲーム（MMORPGなど）は、位置ごとにまとめて必要な対象だけを送らないと、サーバーCPUのボトルネックを避けられない
あわせて読みたい原因
同じ層：L1 クライアントのゲームプロセス
同じ症状（早送り）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る