ゲームラグ白書 › L9 サーバーのゲームプロセス
シリアライズ・圧縮のコスト Serialization / compression cost
原因ID sp-serialize · 主担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
送るデータをバイト列に変換して圧縮するのにもCPUを使い、人が多いとこのコストが急増します。
なぜ 更新のたびに構造体をバイト列に変換・圧縮 → すると 人数の2乗に比例してコストが増加 → 画面では 送信が遅れて入力遅延
症状 入力遅延
要因 ストール, 遅延
誰に起きるか 特定の場所・チャンネル
いつ 人が集中したとき
担当 主担当 ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応 一度作ったパケットを複数人に再利用、軽量なフォーマット。
グラフでは 人数・負荷に連動して上昇 · サーバーのCPU使用率、パケットを作るスレッドのCPU
確認箇所 perf top -pで、ゲームプロセスのCPU時間に占めるシリアライズ・圧縮・暗号化の関数(zlib・LZ4・OpenSSLのようなライブラリの関数を含む)の比率を、人数が少ないときと集中したときで比較 該当する場合 人数が集中するほどシリアライズ・圧縮・暗号化の関数の比率が大きくなり、パケットを作るスレッドのCPUが先に飽和 該当しない場合 これらの関数の比率が小さければ、視界計算・ゲームロジックの側 確認手段 インフラのツールで確認(ゲームコード不要)
もっと詳しく パケットを暗号化する接続(TLS・DTLSなど)なら、暗号化・復号にもCPUを使います。暗号化は接続ごとに個別に行うため、一度作ったパケットを複数人に再利用しても、暗号化のコストは受信者の数だけかかります。AES-GCMのような共通鍵暗号はコア1つで毎秒数GBを処理できるほど速く、普段の比率は小さいですが、一度に暗号化する単位(レコード)のサイズによって速度が大きく変わるため、ゲームのように小さいパケットが多いとバイトあたりのコストが大きくなります。接続ごとに一度行うハンドシェイクでは、サーバーが証明書の鍵で署名し、鍵交換(ECDHE)を計算します。コア1つあたり毎秒の署名は約1,100回(RSA 2048)から1万8千回(ECDSA P-256)、鍵交換は約9千回程度なので、ログインが集中すると負担になります。
出典 Introduction to Iris in Unreal Engine Epic Games レプリケーションする状態を量子化したコピー1つで保持して重い処理を減らし、その処理を複数の接続で共有 VALORANT's 128-Tick Servers Riot Games 毎フレーム、レプリケーション変数をクライアントごとに比較して変わった値をまとめる方式は、メモリをあちこち読む遅い処理なので、サーバーのCPUを大きく消費 How "expensive" is crypto anyway? Cloudflare BoringSSLでの測定:AES-128-GCMは毎秒約3.7GB(レコードサイズによって大きく変わる)、コア1つあたり毎秒RSA 2048署名1,120回・ECDSA P-256署名18,477回・P-256 ECDHE 9,394回、CloudflareのエッジサーバーでTLSライブラリが使ったCPUは約1.8% perf-top(1) — Linux manual page perf 実行中のプロセス(-p)のCPU使用比率を関数(シンボル)ごとにリアルタイム表示
あわせて読みたい原因
同じ層:L9 サーバーのゲームプロセス
同じ症状(入力遅延)を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る