Messen Sie die Leistung Ihrer Firebase Realtime Database mit dem Datenbankprofiler Tool, das in die Firebase CLI integriert ist. Das Profiler-Tool protokolliert alle Aktivitäten in Ihrer Datenbank über einen bestimmten Zeitraum und erstellt dann einen detaillierten Bericht. Mit dem detaillierten Bericht können Sie Probleme mit der Datenbankleistung beheben, Problembereiche erkennen und nicht indexierte Abfragen reduzieren.
Profil erstellen
Bevor Sie mit der Profilerstellung für Ihre Firebase Realtime Database beginnen, müssen Sie die aktuelle Version der Firebase CLI verwenden und sie für die Datenbank und das Projekt initialisieren, für die Sie ein Profil erstellen möchten. Sie müssen Bearbeiter oder Inhaber dieses Projekts sein, um ein Profil zu erstellen.
Starten Sie die Profilerstellung für Ihre Datenbank mit dem folgenden Befehl:
Der Profiler zeigt eine Statusmeldung an, während er Vorgänge aus Ihrer Datenbank aufzeichnet und das Profil erstellt.firebase database:profile
Drücken Sie die Eingabetaste, um das Profil zu vervollständigen und die Ergebnisse anzuzeigen.
Ergebnisse auswerten
Das Profiler-Tool fasst die Daten zusammen, die es zu den Vorgängen Ihrer Datenbank erfasst hat, und zeigt die Ergebnisse in drei Hauptkategorien an: Geschwindigkeit, Bandbreite und nicht indexierte Abfragen.
Geschwindigkeit
Im Geschwindigkeitsbericht wird die Antwortzeit des Servers (in Millisekunden) für jeden Vorgangstyp gemessen. Die im Geschwindigkeitsbericht gemessene Geschwindigkeit spiegelt jedoch möglicherweise nicht die Geschwindigkeit wider, die Endnutzer erleben. Verschiedene Faktoren, einschließlich der Netzwerkbedingungen, können die Latenz auf der Clientseite erhöhen.
Der Geschwindigkeitsbericht enthält die folgenden Attribute:
- Pfad:Der Pfad in Ihrer Datenbank, in dem die Vorgänge ausgeführt wurden. Wenn mehr als 25 untergeordnete Knoten vorhanden sind, fasst das Profiler-Tool diese in einem übergeordneten Pfad zusammen und fügt einen
$wildcard-Marker hinzu. Möglicherweise sehen Sie im Bericht das Stammverzeichnis Ihrer Datenbank, das durch einen Schrägstrich/dargestellt wird. - Anzahl:Die Anzahl der Vorgänge, die im angegebenen Pfad ausgeführt wurden.
- Durchschnittliche Ausführungsgeschwindigkeit:Die durchschnittliche Zeit, die der Server benötigt, um die Geschäftslogik auszuführen, die zur Verarbeitung des jeweiligen Vorgangstyps in diesem Pfad erforderlich ist. Das hier gemessene Zeitintervall beginnt nach dem, das durch die unten beschriebene „Durchschnittliche Wartezeit“ gemessen wird.
- Durchschnittliche Wartezeit:Die durchschnittliche Zeit, die Anfragen in der Warteschlange verbringen, bevor sie ausgeführt werden. Diese Verzögerung ist bei allen vom Client initiierten Anfragen üblich. Die Gesamtlatenz der serverseitigen Anfrage ist ungefähr die Summe aus der Wartezeit und der Ausführungsgeschwindigkeit dieser Anfrage.
- Berechtigung verweigert: Die Anzahl der Vorgänge im angegebenen Pfad, die von den Firebase Database Rules in Ihrer Datenbank blockiert wurden.
| Geschwindigkeitsbericht nach Vorgangstyp | |
|---|---|
| Lesegeschwindigkeit | Die Serverantwortzeit für Clientanfragen zum Lesen von Daten aus der Datenbank. Die Leseausführungszeit skaliert im Allgemeinen mit der Menge der gelesenen Daten. Auch einige kleine Lesevorgänge können durch das Cache-Prefetching verzögert werden. |
| Schreibgeschwindigkeit | Die Serverantwortzeit für Clientanfragen zum Schreiben von Daten in die Datenbank. Die Schreibausführungszeit skaliert mit der Menge der geschriebenen Daten. |
| Verbindungsgeschwindigkeit | Die Serverantwortzeit für Anfragen zum Herstellen einer Verbindung zu Datenbankclients. Die Latenz für Verbindungsanfragen wird durch die serverseitige Buchführung im Arbeitsspeicher im Zusammenhang mit der Verbindungsverwaltung dominiert. |
| Broadcast-Geschwindigkeit | Die Zeit, die der Server benötigt, um Daten an Clients zu verteilen, die den angegebenen Pfad auf Echtzeitaktualisierungen überwachen. Das Attribut Anzahl im Bericht zur Broadcast-Geschwindigkeit fasst die Anzahl der Broadcasts zusammen, nicht die Anzahl der Clients, die die Informationen erhalten haben. Wenn beispielsweise 10 Clients einen bestimmten Pfad überwachen und der Server eine Aktualisierung an alle 10 Clients sendet, wird in der Anzahl der Broadcasts nur 1 Broadcast angezeigt, obwohl 10 Clients die Daten erhalten haben. Das Attribut Berechtigung verweigert ist nicht im Bericht zur Broadcast-Geschwindigkeit enthalten. |
Bandbreite
Der Bandbreitenbericht gibt Aufschluss darüber, wie viele Daten Ihre Datenbank bei eingehenden und ausgehenden Vorgängen verbraucht. Sie sollten den Bandbreitenbericht jedoch nicht verwenden, um die Abrechnung zu schätzen, da er keine Bandbreite enthält, die für andere Vorgänge verwendet wird, z. B. für die Profilerstellung für Ihre Datenbank. Der Bandbreitenbericht schätzt die Nutzlastgröße der Daten, die bei Lese-, Schreib- und Broadcast-Vorgängen in und aus Ihrer Datenbank verbraucht werden. Es ist ein Tool zur Messung der Leistung, nicht zur Prognose der Abrechnung.
Der Bandbreitenbericht enthält die folgenden Attribute:
Pfad:Der Pfad in Ihrer Datenbank, in dem die Vorgänge ausgeführt wurden. Wenn mehr als 25 untergeordnete Knoten vorhanden sind, fasst das Profiler-Tool diese in einem übergeordneten Pfad zusammen.
Gesamt:Die Gesamtzahl der ausgehenden oder eingehenden Byte, die bei allen Vorgängen im angegebenen Pfad verwendet wurden.
Anzahl:Die Anzahl der Vorgänge, die im angegebenen Pfad ausgeführt wurden.
Durchschnitt:Die durchschnittliche Anzahl der heruntergeladenen oder hochgeladenen Byte bei Vorgängen im angegebenen Pfad (Byte/Schreibvorgang oder Byte/Lesevorgang).
| Bandbreitenbericht | |
|---|---|
| Heruntergeladene Byte | Daten, die bei Lese- und Broadcast-Vorgängen verbraucht werden, die über die Client-SDKs und die REST API gesendet werden. |
| Hochgeladene Byte | Daten, die bei Schreibanfragen verbraucht werden, die an den Datenbankserver gesendet werden. Löschvorgänge werden als Schreibvorgänge mit 0 Byte unter „Eingehend“ angezeigt. |
Nicht indexierte Abfragen
Nicht indexierte Abfragen können teuer sein, da Clients alle Daten an einem Speicherort herunterladen und dann Abfragen darauf ausführen. Dadurch wird mehr Bandbreite als nötig verbraucht. Beheben Sie so viele nicht indexierte Abfragen wie möglich, um die Leistung Ihrer Datenbank zu optimieren.
Der Bericht zu nicht indexierten Abfragen enthält die folgenden Attribute:
- Pfad:Der Pfad in Ihrer Datenbank, in dem die nicht indexierten Abfragen ausgeführt wurden.
- Index:Die Regel, die Sie hinzufügen sollten, um die nicht indexierten Abfragen zu beheben. Weitere Informationen zur Indexierung finden Sie unter Daten indexieren.
- Anzahl:Die Anzahl der nicht indexierten Abfragen, die im angegebenen Pfad ausgeführt wurden.
Erweiterte Profilerstellung
Wenn Sie alle Vorgänge sehen möchten, die Ihre Datenbank verarbeitet, verwenden Sie das Flag --raw, wenn Sie ein Profil für Ihre Datenbank erstellen. Beispiel:
firebase database:profile --raw
Die Rohausgabe enthält auch Clientinformationen für jeden Vorgang, z. B. userAgent-Strings und IP-Adressen. Weitere Informationen zu den verschiedenen Vorgängen
, für die in Ihrer Firebase Realtime Database ein Profil erstellt wurde, finden Sie unter Firebase Realtime Database Operation Types.
Das Profiler-Tool: Kein Abrechnungstool
Verwenden Sie das Profiler-Tool nicht, um die Bandbreitenkosten zu schätzen. Das Profiler-Tool soll Ihnen einen Überblick über die Leistung Ihrer Datenbank geben, damit Sie Vorgänge überwachen und Probleme beheben können. Es ist nicht dazu gedacht, die Abrechnung zu schätzen. Es berücksichtigt keinen Netzwerk-Traffic, sondern erfasst nur eine Schätzung der Anwendungsdaten, die in Antworten gesendet werden.
Im Folgenden finden Sie einige häufige Beispiele für Netzwerk-Traffic, der von Firebase in Rechnung gestellt wird und nicht in Ihrem Datenbankprofil enthalten ist:
- Protokoll-Overhead:Für das Einrichten und Aufrechterhalten einer Sitzung ist zusätzlicher Traffic zwischen dem Server und den Clients erforderlich. Je nach zugrunde liegendem Protokoll kann dieser Traffic Folgendes umfassen: Protokoll-Overhead der Firebase Realtime Database, WebSocket-Overhead und HTTP-Header-Overhead. Jedes Mal, wenn eine Verbindung hergestellt wird, trägt dieser Overhead zusammen mit dem SSL-Verschlüsselungs-Overhead zu den Verbindungskosten bei. Obwohl dies in der Regel keine große Bandbreite ist, kann sie erheblich sein, wenn Ihre Nutzlasten klein sind oder Sie häufige, kurze Verbindungen herstellen.
- SSL-Verschlüsselungs-Overhead:Für den SSL-Verschlüsselungs-Overhead, der für sichere Verbindungen erforderlich ist, fallen Kosten an. Im Durchschnitt betragen diese Kosten etwa 3,5 KB für den ersten Handshake und etwa 40 Byte für TLS-Datensatzheader in jeder ausgehenden Nachricht. Bei den meisten Apps macht dies einen kleinen Prozentsatz Ihrer Rechnung aus. Dies kann jedoch ein großer Prozentsatz sein, wenn in Ihrem Fall viele SSL-Handshakes erforderlich sind. Bei Geräten, die keine TLS-Sitzungstickets unterstützen, sind beispielsweise möglicherweise viele SSL-Verbindungs-Handshakes erforderlich.
Weitere Informationen zum Nachvollziehen und Schätzen Ihrer Rechnung.