パフォーマンスの問題を特定する

パフォーマンスの問題を特定することは、一般的にフレームレート（計算）、メモリ、またはロード時間のいずれかのカテゴリに掘り下げることを意味します。

Robloxには、パフォーマンスの問題を特定するためのいくつかのツールがあり、その中にはRobloxクライアント（したがってStudioでも）で利用できるものと、Studioでのみ利用できるものがあります。クライアントの動作を直接観察できる一方で、サーバーの問題を診断するにはツールを使用する必要があります。

診断ツール

サーバー計算

サーバーハートビートはすべてのゲームで60 FPSに制限されているため、低い値はパフォーマンスの問題を示している可能性があります。サーバーハートビートを確認するには：

• 開発者コンソールを使用して - サーバージョブタブで、ハートビート行を展開し、ゲームのハートビートを表す秒あたりのステップ値を確認します。

• MicroProfilerを使用して、フレームが16.67 ms以上かかっているかどうかをグラフで確認できます。

  MicroProfilerは、特定のフレームが他のフレームよりも処理にかなり長い時間がかかる「スパイク」を特定するのに特に役立ちます。

サーバーハートビートが低下している別の症状は、レイテンシの増加（一般的にピングとして知られる）です。サーバーが各フレームのタスクを完了するのに時間がかかるほど、クライアントから送受信されるネットワークデータを処理するのに時間がかかります。サーバーに接続されているすべてのプレイヤーの平均ピングを確認するには、開発者コンソールのサーバー統計タブに移動します。

パフォーマンスを改善した後もサーバーハートビートが低いままである場合、ゲームはデフォルトでサーバーが得られるCPU以上のCPUを必要とする可能性があります。より多くのCPUを予約するには、計算のための拡張サービスを使用できます。

クライアント計算

デフォルトのクライアントフレームレート制限は60 FPSです。ただし、ユーザーはWindowsでフレームレート制限を最大240 FPSまで引き上げることができます。

フレームレートはデバイスによって大きく異なります。たとえば、高性能のPCは計算問題を「強引に」解決でき、ほとんど気づかないフレームレートの低下を経験するかもしれません。低性能のデバイスでテストすると、問題はより深刻であり、したがって気づきやすくなります。

ゲームのフレームレートを確認するには：

• クライアントでShiftF5を押してデバッグ統計の概要を表示します。

• Studioのウィンドウ ⟩ パフォーマンスメニューから、統計をオンにしてデバッグ統計を有効にします。

  Studioのパフォーマンス統計はStudioアプリケーションによって歪められるため、正確な数値を得るにはクライアントでフレームレートを確認する必要があります。

• MicroProfilerを使用して、フレームが16.67 ms以上かかっているかどうかをグラフで確認できます。

サーバーメモリ

サーバーメモリ使用量を50%未満に保つようにしてください。サーバーの総メモリは次の式を使用します：

6.25 GiB + (100 MiB * 最大接続プレイヤー数)

たとえば、30人のプレイヤーが接続されているサーバーは、約9.18 GiBの総メモリを持っています。プレイヤーが接続するとサーバーはメモリを増やしますが、プレイヤーが切断されるとメモリは減少しません。10人のプレイヤーが離れても、サーバーは9.18 GiBのメモリを保持し、8.2 GiBに縮小することはありません。

サーバーがシャットダウンすると（たとえば、空である場合や更新プロセスの一環として）、その代替品は基本のメモリ量から始まり、プレイヤーが接続するにつれてスケールアップを開始します。

クライアントメモリ

ゲームのメモリ使用量を確認する方法はいくつかあります：

1. 開発者コンソールを開き、メモリタブに切り替えます。このタブでは、メモリがどのように割り当てられているかの内訳が表示されます。最も正確な読み取り値を得るには、Studioではなくクライアントを使用してください。
2. クライアントの設定メニューからパフォーマンス統計ビューを有効にして、クライアントの総メモリ使用量を表示するオーバーレイを確認します。

高いメモリ使用量は必ずしも問題を示すものではありませんが、さらに調査が必要な兆候としては以下のようなものがあります：

• パフォーマンスダッシュボードに表示されるクライアントクラッシュの割合が大きい場合、特に更新と一致する突然の増加がある場合。ある程度のクラッシュは予想されますが、クラッシュ率が2-3%を超える場合は調査する必要があります。
• ゲームがサポートすることを望むデバイスでテスト中にクラッシュが発生する場合。

クライアントのゲームメモリ消費の大部分は、メモリに読み込まれたアセット（画像、メッシュ、オーディオファイルなど）から来ています。開発者コンソールで、PlaceMemoryの下にある以下のラベルを確認してください：

• GraphicsMeshParts - メッシュによって消費されるグラフィックスメモリ。
• GraphicsTexture - テクスチャによって消費されるグラフィックスメモリ。
• Sounds - オーディオファイルによって消費されるメモリ。

ロード時間

ロード時間、または参加時間は、プレイヤーがプレイをクリックしてから、世界がレンダリングされてプレイを開始できるまでの合計時間です。クライアントがサーバーに接続した後、参加は次の順序で行われます：

1. ReplicatedFirstがクライアントに複製され、その中のカスタムローディングスクリーンが表示されます。
2. 残りのデータモデルが複製され、ReplicatedStorageとWorkspace内のすべてが含まれます。インスタンスストリーミングを有効にすると、この段階ではプレイヤーのスポーンポイント近くのWorkspaceの領域のみが複製されます。
3. プレイヤーのアバターが読み込まれます。ロード時間は、ローディングスクリーンが消え、世界のレンダリングが始まると終了します。

どのステップが遅いかを知ることで、最も影響の大きい最適化を選択するのに役立ちます。一般的な原因と修正については、パフォーマンスの改善を参照してください。

ロード時間を確認するための組み込みツールはありませんが、ミリ秒単位の精度を必要としないため、ストップウォッチがあれば現在のベースラインを理解し、実質的な改善があったかどうかを確認できます。ReplicatedFirst内のクライアントスクリプトを使用して、変更がロード時間にどのように影響するかを把握することができますが、このスクリプトは完全なエンドツーエンドの測定を提供するものではありません。ReplicatedFirstが複製された後にタイミングを開始し、初期複製が完了しDataModel.Loadedが発火したときに停止するため、サーバーへの接続時間やアバターの読み込み時間は含まれません：

local startTime = os.clock()

game.Loaded:Connect(function()
  local loadTime = os.clock() - startTime
  local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- 小数点以下4桁
  print("ゲームが " .. roundedLoadTime .. " 秒で読み込まれました。")
  print("読み込まれたインスタンスの数: " .. #workspace:GetDescendants())
end)

追加の洞察を得るために、スタジオ設定のネットワークタブから参加サイズの内訳を印刷を有効にして、ゲームをスタジオで開始したときにサイズ別の上位20インスタンスとインスタンスタイプ別のパーセンテージ内訳を印刷します。

ロード時間がゲームの見かけのサイズに対して予想外に高い場合は、認識されていないまたは難読化されたスクリプトがプレースに存在するかどうかを確認してください。クリエイターストアからの一部の無料モデルには、プレイヤーが参加する際に複製する必要があるデータ量を劇的に増加させる数千の追加インスタンスを生成するスクリプトが含まれています。

各最適化または更新の前後でロード時間を測定し、その影響を確認し、回帰をキャッチできるようにします。突然の増加は、最近ReplicatedStorageにコンテンツが追加されたか、アセットの変更によりダウンロードサイズが増加したことを意味することがよくあります。

ピング

ピング（レイテンシ）の主な2つの測定値は、ネットワークピングとデータピングです。

ネットワークピングは、クライアントがネットワークデータパケットを送信してから、サーバーのエコー応答を受信するまでの往復時間です。これは、一般的な目的のピングネットワークユーティリティによって報告されるtimeに似ています。

ネットワークピングはパフォーマンス統計バーに表示されます。これは主にクライアントとサーバー間のネットワークパスの長さによって影響を受け、あなたの制御外です。ただし、スタジオでプレイテスト中にネットワークシミュレーションを使用してピングやその他のネットワーク条件をシミュレートできます。

データピングは、クライアントが複製システムを介してデータを信頼性を持って送信してから、サーバーの複製システムからエコー応答を受信するまでの往復時間です。これは、クライアントとサーバーの両方の複製キューで費やされた時間と、失われたまたは破損したパケットのTCPのような再送信を含みます。

データピングは、クライアントから信頼性のあるリモートイベントを送信し、サーバーで受信し、その後サーバーからクライアントに応答として信頼性のあるリモートイベントを送信することに似ています。データピングには、クライアントとサーバー間のネットワークで費やされた時間も含まれるため、データピングはネットワークピング以上または等しい値になります。

サーバーに接続されているすべてのプレイヤーの平均データピングは、開発者コンソールのサーバー統計タブに表示されます。個々のクライアントのデータピングは、ShiftF3を使用してネットワークデバッグ統計を表示することで確認できます。

データピングは、ネットワークパスと複製キューの遅延の両方によって影響を受けます。サーバーがネットワークが送信できるよりも速く（またはクライアントが処理できるよりも速く）複製データを生成すると、データは複製キューで待機する必要があります。データピングとネットワークピングの間にいくらかの違いがあるのは正常ですが、データピングがネットワークピングよりも大幅に高い場合は、MicroProfilerを使用してネットワークトラフィックを表示してください。最適化の提案については、ネットワーキングと複製を参照してください。