データベースのプロファイルを作成する

Firebase CLI に組み込まれているデータベース プロファイラ ツールを使用して、Firebase Realtime Database のパフォーマンスを測定します。プロファイラ ツールは、特定の期間内に発生したデータベースのすべてのアクティビティをログに記録し、詳細なレポートを生成します。この詳細なレポートを使用して、データベースのパフォーマンスに関する問題をトラブルシューティングし、問題の領域を特定して、インデックス付けされていないクエリを減らすことができます。

プロファイルを作成する

1. Firebase Realtime Database のプロファイル作成を開始する前に、最新バージョンの Firebase CLI を使用していること、プロファイルを作成するデータベースとプロジェクトに対して CLI を初期化していることを確認します。プロジェクトのプロファイルを作成するには、自分がそのプロジェクトの編集者またはオーナーである必要があります。

2. 次のコマンドを使用して、データベースのプロファイル作成を開始します。

   firebase database:profile

   プロファイラがデータベースのオペレーションを記録してプロファイルを作成している間、ステータス メッセージが表示されます。

3. プロファイルの作成が完了したら、Enter キーを押して結果を表示します。

結果を解釈する

プロファイラ ツールは、データベースのオペレーションに関して収集したデータを集計し、速度、帯域幅、インデックス付けされていないクエリという 3 つの主要カテゴリに分けて結果を表示します。

速度

Speed Report は、オペレーション タイプごとにサーバーのレスポンス時間（ミリ秒単位）を測定します。ただし、Speed Report で測定される速度は、エンドユーザーが体感する実際の速度を反映していない場合があります。これは、ネットワーク条件などのさまざまな要因によってクライアント側で遅延が発生する可能性があるためです。

Speed Report には次のプロパティが含まれます。

• Path: オペレーションが発生したデータベース内のパス。子ノードの数が 25 を超えると、子ノードを親のパスにまとめて $wildcard マーカーが追加されます。データベースのルート ディレクトリはスラッシュ（/）としてレポートに表示されます。
• Count: 指定されたパスで発生したオペレーションの数。
• Average: 指定されたパスで、サーバーが特定のタイプのオペレーションを処理するのに要した平均時間。
• Permission Denied: 指定されたパスで、データベースの Firebase Realtime Database ルールによってブロックされたオペレーションの数。

帯域幅

Bandwidth Report を見ると、データベースで送受信のオペレーションに使用されているデータ量がわかります。ただし、Bandwidth Report には他のオペレーション（データベースのプロファイル作成など）に使用された帯域幅は含まれないため、このレポートを料金の見積もりに使用しないでください。Bandwidth Report で示されるのは、データベースとの間で発生する読み取り、書き込み、ブロードキャストのオペレーションで使用されるデータのペイロード サイズの概算です。つまり、これはパフォーマンスの測定ツールであり、料金を予測するツールではありません。

Bandwidth Report には次のプロパティが含まれます。

• Path: オペレーションが発生したデータベース内のパス。子ノードの数が 25 を超えると、子ノードが親のパスにまとめられます。

• Total: 指定されたパスでのすべてのオペレーションで使用された送信バイト数と受信バイト数の合計。

• Count: 指定されたパスで発生したオペレーションの数。

• Average: 指定されたパスでのすべてのオペレーションでダウンロードまたはアップロードされた平均バイト数（書き込みあたりのバイト数、または読み取りあたりのバイト数）。

インデックス付けされていないクエリ

インデックス付けされていないクエリを実行すると、ある場所に存在するすべてのデータがダウンロードされてから検索が実行されるため、コストが大幅に増加する可能性があります。これにより、帯域幅が必要以上に消費されます。インデックス付けされていないクエリをできるだけ多く解決することで、データベースのパフォーマンスを最適化することができます。

Unindexed Queries レポートには次のプロパティが表示されます。

• Path: インデックス付けされていないクエリが発生したデータベース内のパス。
• Index: インデックス付けされていないクエリを解決するために追加すべきルール。インデックス付けの詳細については、データにインデックスを付けるをご覧ください。
• Count: 指定されたパスで発生したインデックス付けされていないクエリの数。

高度なプロファイル作成

データベースで処理されているすべてのオペレーションを表示するには、データベースのプロファイルを作成するときに --raw フラグを次のように使用します。

firebase database:profile --raw

生の出力には、userAgent 文字列や IP アドレスといった各オペレーションのクライアント情報も含まれます。Firebase Realtime Database でプロファイル作成される各オペレーションの詳細については、Firebase Realtime Database オペレーションのタイプをご覧ください。

プロファイラ ツール: 料金ツールではない

プロファイラ ツールを帯域幅コストの見積もりに使用しないでください。 プロファイラ ツールは、データベース パフォーマンスの全体像を把握して、オペレーションの監視や問題のトラブルシューティングに役立てるためのツールであり、料金を見積もるためのツールではありません。ネットワーク トラフィックは考慮せず、レスポンスで送信されるアプリケーション データの予測のみ記録します。

データベースのプロファイルには含まれず、Firebase で課金されるネットワーク トラフィックの一般的な例としては、以下のものが挙げられます。

• プロトコルのオーバーヘッド: セッションを確立して維持するためには、サーバーとクライアント間に追加トラフィックが必要です。このトラフィックには、基盤となるプロトコルに応じて Firebase Realtime Database のリアルタイム プロトコル オーバーヘッド、WebSocket オーバーヘッド、HTTP ヘッダー オーバーヘッドが含まれます。このようなオーバーヘッドは SSL 暗号化オーバーヘッドと併せて、接続が確立されるたびに接続コストが発生する原因となります。一般的に、それほど大きな帯域幅にはなりませんが、ペイロードが小さい場合や頻繁に短い接続を繰り返す場合は、それなりのコストとなる可能性があります。
• SSL 暗号化オーバーヘッド: セキュアな接続に必要な SSL 暗号化オーバーヘッドに関連してコストが発生します。このコストの平均は、最初のハンドシェイクで約 3.5 KB、各送信メッセージの TLS レコード ヘッダーごとに約 40 B です。ほとんどのアプリにおいて、このコストは課金のうちわずかな割合にすぎません。ただし、多くの SSL ハンドシェイクを必要とする特殊なケースの場合は、この割合が大きくなることがあります。たとえば、TLS セッション チケットをサポートしていないデバイスでは、多数の SSL 接続ハンドシェイクが必要になる場合があります。

詳しくは、課金と料金の見積もりについての記事をご覧ください。