パフォーマンステスト
パフォーマンステスト（すなわち負荷テスト）はサーバーサイドの実装やハードウェアが、想定される負荷に対応できるかを検証するうえで非常に効果的な手法です。
想定すべき事項
1台のPhoton Serverが処理できる同時接続ユーザー数は？という単純な質問が、よく寄せられます。
残念ながら、答えはそれほど単純ではありません。それは複数の要因があるためです。たとえば：
- ゲームルームごとのクライアント数
- メッセージ率（ルームごと、1秒あたりのメッセージ数の組み合わせ）
- メッセージのサイズ
- プロトコルの種類（高信頼性/低信頼性）
- クライアントのプラットフォーム
- サーバーハードウエアのスペック
- その他
一般的な使用例の場合、200メッセージ/ルーム/秒 以下です。
以下が標準的な設定です：
- クアッドコア（例：Intel Xeon E3-1270 v3、3.5GHz）
- 8 GB RAM
- 1 GBps NIC/アップリンクポート速度
標準的な構成の場合、Photonは1台のサーバーで2,000～3,000CCUに対応可能です。
通常、ボトルネックはCPUではなくNICまたはトラフィックです。
通常、トラフィックプールはCPUよりも負荷が高いため、小規模なサーバーを使用したほうが効率が高まります。
一般的に、VMよりもベアメタルサーバーのほうが良い結果を得られます。
ただし、上記の数値は想定されるものの概算にすぎません。個々のユースケースに応じて正確な数値を把握するには、調整したうえで負荷テストをおこなう必要があります。
テストシナリオの設定
負荷テストを実行する前にユースケースを確認し、事前に計算をおこなっておきましょう。
利用するサーバーのハードウエアスペック
想定されるCCU数
ゲームの種類、マッチメイキングの方法、機能ごとに異なるサーバーが必要か
SDKのコードをそのまま使用しているか、コードをカスタマイズしているか、カスタマイズしている場合には主な変更点はなにか
1ルームあたりのクライアント数
送信されるメッセージ数
例：4クライアント/ルームで、100ミリ秒ごとにRaiseEvent() をコール
- 受信: 410メッセージ/秒 = 40メッセージ/秒
- 発信： 440メッセージ/秒 = 160メッセージ/秒
- 合計: 200メッセージ/ルーム/秒平均的なメッセージサイズ
- 例:
- 200メッセージ/ルーム/秒 * 200バイト= ～40kBまで/秒/ルーム
- 想定: 1000CCU/250ルーム=> 合計～10MB/秒
- 例:
上記例の数値の場合、100Mbit/秒のアップリンクポート速度の上限にすでに近い状態ということになります。
いくつかのクライアントライブラリには「Network Traffic Stats」が組み込まれているので、上記リストの情報を入手する際に参照してください。
テストクライアントの構築
Photonは大量の接続やトラフィックを処理できるよう最適化されていますが、クライアントSDKやライブラリは負荷テスト用に作られていないため、
クライアントサイドはPhotonと同じように最適化することはできません。
多くの場合、負荷テストをおこなう際には「ゲームクライアント」の実装は完了しています。
そのため、実際のゲームクライアントを再利用して負荷テストを簡単におこなえるように思えるかもしれませんが、PhotonのクライアントSDKで「負荷テストクライアント」を構築してもクライアントがボトルネックとなり、正しい結果を得られません。
負荷テストをおこなうには、適切なテストクライアントの構築が非常にむずかしい課題となります。
以下のアプローチを推奨します：
- ゲームクライアントから送られる代表的なオペレーション／イベントのシーケンスを書き留める。
- ゲームクライアントの挙動を再現する、簡素化されたPhoton Server（！）アプリケーションを構築する。
- Photonのサーバー間機能を使用して、「S2S負荷テストアプリケーション」と「サーバーサイド」Photon間の接続を確立する。
Photonの設定
Photon / PhotonServer.config:
- デフォルトの設定を使用し、なにも変更をおこなわない。
- デフォルトの設定は、幅広い用途に対応できるよう最適化されています。
変更を加えると予期せぬ影響が発生し、テスト結果の理解や分析が困難になる可能性があります。
Logging / log4net.config:
- すべてのlog4net.configファイルでログレベルが「INFO」になっていることを確認してください。
- ログレベルが「DEBUG」で過剰にロギングすると、パフォーマンスに大きく影響しますので回避してください！
- ロギングの詳細はこちらを参照してください： https://logging.apache.org/log4net/release/config-examples.html
テストを実行
- Photon S2S負荷テストクライアントを、個別の物理マシンにホスティングしてください。
- 通常、各「サーバーサイド」のPhotonに負荷を均等に分散するには、最低でも2つの「S2S負荷テストマシン」が必要です。
テストを実行する前に、サーバサイドおよびクライアントマシン上にパフォーマンスカウンターがインストールされ、パフォーマンスカウンターログが作成されている点を確認してください。
- 稼動している場合にはPhotonを停止します。
- Photon ControlからPerformance Counters -> Install Countersへと進み、Logging Setを作成します。
- コマンドラインから「perfmon」を起動します。「data collector sets」の下から「User Defined」へ進み、右のウィンドウペインからphoton_perf_logを選択します。その後、Propertiesへと進み、sample intervalを1秒に設定してください（デフォルトの1分だと、十分なデータを得られません）。
- Photonを起動します。
- Photon Controlから、Performance Counters -> Start Loggingへ進みます。
- 負荷テストを実行します。
- Photon ControlからPerformance Counters -> Stop Loggingへ進みます。
- C:\perflogs\adminからパフォーマンスログを取得します。
- \deploy\bin_win64\log and \deploy\logからログファイルを取得します。
Photon Controlからのログ作成が失敗する場合は、\deploy\bin_tools\perfmon:から以下のコマンドを実行してください：
logman.exe create counter photon_perf_log -si 00:01 -v mmddhhmm -cf logman.config.txt
パフォーマンスの分析とボトルネックの特定
負荷を分析するには、perfmonでパフォーマンスカウンターを読み込んでください。
Photon Server SDKの「doc」フォルダ内の「photon-perfcounter.pdf」に、すべてのカウンターのリストと簡単な説明が記載されています。
「全体」の負荷を概算:
最初の概算では、以下のような「明らかな」カウンターを参照します：CPU負荷、アクティブなピア/接続数、プロセスごとのメモリ使用率、切断、ネットワークトラフィックなど（バイト単位での受信/発信・合計）。これらのカウンターを確認することで、サーバーが想定通りに負荷を処理しているか、またはさらに調査が必要かの判断が出来ます。
送信トラフィック（クライアントがビジーか？）:
上記のとおり、しばしばクライアントサイドがボトルネックになります。Commands Resent/秒の量（クライアントがACKを送信しない場合、Photonはコマンドを再送信します）や、Queued Reliable Commandsの量（送信されたが、まだ確認されていないコマンドの量）などを参照し「送信」トラフィックがどのように処理されているかを十分に確認してください。
これらの値が高い場合には、クライアントサイドで問題が発生している可能性が非常に高いです。
必ずこれらのカウンターを確認し、クライアントサイドのボトルネックが見つかった場合には解決してから、テストを再実行してください。
受信トラフィック（サーバーがビジーか？）:
いくつの「アクティブ」な受信/発信、ビジネスおよびENet Threadが現在処理されているかを比較し、サーバーがビジーかを確認します。
これらのカウンターはCPU/メモリ使用率カウンターと相互に関係している場合が多いため、これらから新たな情報を得られることはあまりありません。
サポートが必要な場合
サポートが必要な場合や、ご質問がある場合には、[email protected]までメールを送信ください。
特に以下については、出来る限り多くの情報を記載してください：
- 「テストシナリオの設定」セクションに記載された、すべての設定値および想定値
- 「テストを実行」セクションで取得した、すべてのログファイルおよびパフォーマンスカウンターログ