このページは編集中です。更新が保留になっている可能性があります。
server | v5 switch to v4  

パフォーマンスのヒント

パフォーマンスは、アプリケーションにマルチプレイヤー・コンポーネントを流動的かつシームレスに統合するために欠くことができない部分です。 そのため、ここではPhotonで開発する際に覚えておくべきヒントのリストをまとめました。

サービスを定期的に呼び出す

クライアントのライブラリは、アプリのロジックにトリガーされた場合にのみ任意のメッセージを送信するように構築されています。このようにして、クライアントは複数の操作を集約してネットワークのオーバーヘッドを回避することができます。

データの送信をトリガーするには、メインループで LoadBalancingClient.Service() または PhotonPeer.SendOutgoingCommands() を頻繁に呼び出す必要があります。まだキューに入っているデータがある場合、boolの戻り値はtrueです。その場合は、再度SendOutgoingCommandsを呼び出してください (ただし連続して3回まで)。

ServiceとSendOutgoingCommandsは、接続を維持するために重要な確認応答とpingも送信します。どちらも呼び出しの間の長い休止は避けた方が良いでしょう。特に、ロード中にもかかわらずServiceが呼び出されるようにしてください。

この問題は、見落とされると特定や再現が難しくなります。C#ライブラリにはConnectionHandlerがあり解決に役立ちます。

ローカルのラグを避けるには、ゲームループがネットワークのアップデートを書いた後にSendOutgoingCommandsを呼び出します。

トップに戻る
 

アップデート Vs トラフィック

1秒間ごとのアップデート数を増やすと、ゲームがより流動的かつ最新のものとなります。 一方で、トラフィックが劇的に増加する場合があります。また、ランダムなラグやロスを避けることはできないのでアップデートの受信者は常に重要な値を補間できるようにしなければなりません。

以下の点に留意してください。呼び出した操作の多くは他のプレイヤーにイベントを作成するため、1秒あたりのアップデートの送信回数が少ない方が処理が速い可能性があります。

トップに戻る
 

トラフィックの最適化

トップに戻る
 

データの作成と消費

「トラフィック」のトピックに関連した問題として、受信側の末端で消費可能な量のデータしか生成されない問題が挙げられます。 パフォーマンスやフレームレートが受信イベントに追い付いていけない場合、それらは実行される前に古くなってしまいます。

最悪のケースでは、一方の側が受信側の末端を壊すほど多くのデータを生成します。 開発中には、クライアントの待ち行列の長さに注意してください。

トップに戻る
 

信頼性の低いコマンドの実行を制限

クライアントが受信メッセージをしばらくディスパッチしなくても(例:ローディング中に)、クライアントはすべての受信とバッファリングをおこないます。 他のプレイヤーのアクティビティーに応じて、クライアントは追いつくまでに膨大な処理をおこなう必要があります。

単純化するため、クライアントは信頼性の低いメッセージを特定の長さに自動的にカットします。 結果的に最新メッセージをより早く取得でき、アップデートされていない箇所は最新のメッセージにすぐに置換されます。

この制限はデフォルトが20の(PUN内も同じ)LoadbalancingPeer.LimitOfUnreliableCommands経由で設定されています。

トップに戻る
 

データグラムのサイズ

データグラムのコンテンツのサイズは、1,200バイトに制限されています。

1,200バイトにはヘッダーからのすべてのオーバーヘッド(「バイナリプロトコル」を参照してください)、サイズおよび型の情報(「photonでのシリアル化」を参照してください)が含まれます。これによって、実際の純粋なペイロード数は若干減少します。 データがどのように構築されたかによって異なりますが、純粋なペイロードデータが1KB未満の場合には単独のデータグラムにおさまると考えて問題ありません。

1,200バイトよりも大きなオペレーションやイベントは分割され、複数のコマンドで送信されます。 これらは自動的に信頼性が高くなり、受信側はすべてのフラグメントを受信後にこれらの大きなデータチャンクを再構成して、ディスパッチできます。

大きなデータ「ストリーム」は、ディスパッチされる前に多くのパッケージから再構成する必要があるため、レイテンシーに大きく影響します。 これらは個別のチャネルに送信可能なため、(低い)チャネル番号の「ライブ」位置アップデートには影響しません。

トップに戻る
 

EventDataの再利用

C#クライアントは、OnEvent(EventData ev)を介してイベントを受信します。デフォルトでは、各EventDataは新しいインスタンスであるため、ガベージコレクターに余分な作業が発生します。

多くの場合、EventDataを再利用することで容易にオーバーヘッドを回避できます。これは PhotonPeer.ReuseEventInstance設定で有効にできます。


ドキュメントのトップへ戻る