Mit dem Datenbank-Profiler in der Firebase CLI können Sie die Leistung Ihrer Firebase Realtime Database messen. Das Profiler-Tool protokolliert alle Aktivitäten in Ihrer Datenbank über einen bestimmten Zeitraum und generiert dann einen detaillierten Bericht. Anhand des detaillierten Berichts können Sie Probleme mit der Datenbankleistung beheben, Problembereiche erkennen und die Anzahl nicht indexierter Abfragen reduzieren.
Profil erstellen
Bevor Sie mit dem Profiling Ihrer Firebase Realtime Database beginnen, prüfen Sie, ob Sie die neueste Version der Firebase CLI verwenden und sie für die Datenbank und das Projekt initialisiert haben, die Sie profilieren möchten. Sie müssen Bearbeiter oder Inhaber des Projekts sein, um es zu erfassen.
Starten Sie mit dem folgenden Befehl die Profilerstellung für Ihre Datenbank:
firebase database:profile
Drücken Sie die Eingabetaste, um das Profil zu vervollständigen und die Ergebnisse anzuzeigen.
Ergebnisse auswerten
Das Profiler-Tool aggregiert die Daten, die über die Vorgänge Ihrer Datenbank erfasst wurden, und zeigt die Ergebnisse in drei Hauptkategorien an: Geschwindigkeit, Bandbreite und nicht indexierte Abfragen.
Geschwindigkeit
Im Bericht zur Geschwindigkeit wird die Antwortzeit des Servers (in Millisekunden) für jeden Vorgangstyp gemessen. Die im Geschwindigkeitsbericht gemessene Geschwindigkeit entspricht jedoch möglicherweise nicht der Geschwindigkeit, die Endnutzer tatsächlich erleben. Verschiedene Faktoren, einschließlich Netzwerkbedingungen, können zu einer Latenz auf der Clientseite führen.
Der Bericht zur Geschwindigkeit enthält die folgenden Properties:
- Pfad: Der Pfad in Ihrer Datenbank, an dem die Vorgänge stattgefunden haben. Wenn es mehr als 25 untergeordnete Knoten gibt, werden diese im Profiler-Tool in einen übergeordneten Pfad verschachtelt und eine Markierung
$wildcardhinzugefügt. Möglicherweise wird im Bericht das Stammverzeichnis Ihrer Datenbank angezeigt, dargestellt durch einen Schrägstrich/. - Anzahl: Die Anzahl der Vorgänge, die am angegebenen Pfad ausgeführt wurden.
- Durchschnittliche Ausführungsgeschwindigkeit: Die durchschnittliche Zeit, die der Server für die Ausführung der Geschäftslogik benötigt, die für die Verarbeitung des jeweiligen Vorgangstyps an diesem Pfad erforderlich ist. Das hier gemessene Zeitintervall beginnt nach dem Zeitintervall, das mit dem unten beschriebenen Messwert „Durchschnittliche ausstehende Zeit“ gemessen wird.
- Durchschnittliche Wartezeit:Die durchschnittliche Zeit, die Anfragen vor der Ausführung in die Warteschlange gestellt wurden. Diese Verzögerung ist bei allen clientinitiierten Anfragen üblich. Die gesamte serverseitige Anfragelatenz ist ungefähr die Summe aus Wartezeit und Ausführungsgeschwindigkeit dieser Anfrage.
- Berechtigung verweigert:Die Anzahl der Vorgänge am angegebenen Pfad, die durch Firebase-Datenbankregeln in Ihrer Datenbank blockiert wurden.
| Geschwindigkeitsbericht nach Vorgangstyp | |
|---|---|
| Lesegeschwindigkeit | Die Serverantwortzeit für Clientanfragen zum Lesen von Daten aus der Datenbank. Die Ausführungszeit von Lesevorgängen skaliert in der Regel mit der Menge der gelesenen Daten. Aber auch einige kleine Lesevorgänge können durch das Cache-Prefetching verzögert werden. |
| Schreibausführungsgeschwindigkeit | Die Serverantwortzeit für Clientanfragen zum Schreiben von Daten in die Datenbank. Die Ausführungszeit für Schreibvorgänge skaliert mit der Datenmenge, die geschrieben wird. |
| Ausführungsgeschwindigkeit von Connect | Die Serverantwortzeit für Anfragen, die an Datenbankclients gesendet werden. Die Latenz für Verbindungsanfragen wird hauptsächlich durch die serverseitige In-Memory-Buchhaltung im Zusammenhang mit der Verbindungsverwaltung bestimmt. |
| Ausführungsgeschwindigkeit der Übertragung | Die Zeit, die der Server benötigt, um Daten an Clients zu verteilen, die den angegebenen Pfad für Echtzeitaktualisierungen beobachten. Die Eigenschaft Count im Bericht zur Übertragungsgeschwindigkeit aggregiert die Anzahl der erfolgten Broadcasts und nicht die Anzahl der Clients, die die Informationen erhalten haben. Wenn beispielsweise 10 Clients an einem bestimmten Pfad lauschten und der Server eine Aktualisierung an alle 10 Clients übertrug, wird in der Anzahl der Übertragungen nur eine Übertragung angezeigt, obwohl 10 Clients die Daten empfangen haben. Die Property Berechtigung verweigert ist nicht im Bericht zur Übertragungsgeschwindigkeit enthalten. |
Bandbreite
Der Bandbreitenbericht gibt Aufschluss darüber, wie viele Daten Ihre Datenbank bei eingehenden und ausgehenden Vorgängen verbraucht. Sie sollten den Bericht zur Bandbreite jedoch nicht für die Abrechnung verwenden, da er die Bandbreite nicht enthält, die für andere Vorgänge wie das Erstellen eines Datenbankprofils verwendet wird. Im Bandbreitenbericht wird die Nutzlastgröße der Daten geschätzt, die bei Lese-, Schreib- und Übertragungsvorgängen von und zu Ihrer Datenbank verbraucht werden. Es ist ein Tool zur Leistungsmessung, keine Prognose für die Abrechnung.
Der Bericht zur Bandbreite enthält die folgenden Properties:
Pfad: Der Pfad in Ihrer Datenbank, an dem die Vorgänge stattgefunden haben. Wenn es mehr als 25 untergeordnete Knoten gibt, werden diese im Profiler-Tool in einen übergeordneten Pfad verschachtelt.
Gesamt: Die Gesamtzahl der ausgehenden oder eingehenden Byte, die für alle Vorgänge am angegebenen Pfad verwendet wurden.
Anzahl:Die Anzahl der Vorgänge, die im angegebenen Pfad aufgetreten sind.
Durchschnitt: Die durchschnittliche Anzahl der heruntergeladenen oder hochgeladenen Byte bei Vorgängen am angegebenen Pfad (Byte/Schreiben oder Byte/Lesen).
| Bericht zur Bandbreite | |
|---|---|
| Heruntergeladene Byte | Daten, die bei Lese- und Broadcast-Vorgängen verarbeitet werden und über die Client-SDKs und die REST API gesendet werden. |
| Hochgeladene Byte | Daten, die durch Schreibanfragen an den Datenbankserver verbraucht werden. Löschvorgänge werden unter „Eingehend“ als Schreibvorgänge mit 0 Byten 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 möglichst viele nicht indexierte Abfragen, um die Leistung Ihrer Datenbank zu optimieren.
Der Bericht „Nicht indexierte Abfragen“ zeigt die folgenden Eigenschaften an:
- Pfad:Der Pfad in der Datenbank, in dem die nicht indexierten Abfragen aufgetreten sind.
- Index: Die Regel, die Sie hinzufügen sollten, um die nicht indexierten Abfragen zu lösen. Weitere Informationen zur Indexierung
- Anzahl:Die Anzahl der nicht indexierten Abfragen, die unter dem angegebenen Pfad aufgetreten sind.
Erweiterte Profilerstellung
Wenn Sie alle Vorgänge sehen möchten, die von Ihrer Datenbank verarbeitet werden, verwenden Sie beim Erstellen des Datenbankprofils das Flag --raw:
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, die in Ihrer Firebase Realtime Database erfasst werden, finden Sie unter Firebase Realtime Database-Vorgangstypen.
Das Profiler-Tool: Kein Abrechnungstool
Verwenden Sie nicht das Profiler-Tool, um die Bandbreitenkosten zu schätzen. Das Profiler-Tool soll Ihnen ein Gesamtbild der Leistung Ihrer Datenbank vermitteln, damit Sie den Betrieb im Blick behalten und Probleme beheben können. Es dient nicht zur Schätzung der Abrechnung. Der Netzwerkverkehr wird nicht berücksichtigt, sondern nur eine Schätzung der Anwendungsdaten, die in Antworten gesendet wurden.
Im Folgenden finden Sie einige häufige Beispiele für Netzwerkverkehr, der von Firebase in Rechnung gestellt wird und nicht in Ihrem Datenbankprofil abgedeckt ist:
- Protokoll-Overhead: Es ist ein gewisser zusätzlicher Traffic zwischen dem Server und den Clients erforderlich, um eine Sitzung herzustellen und aufrechtzuerhalten. Je nach zugrunde liegendem Protokoll kann dieser Traffic Folgendes umfassen: den Overhead des Echtzeitprotokolls von Firebase Realtime Database, den WebSocket-Overhead und den HTTP-Header-Overhead. Jedes Mal, wenn eine Verbindung hergestellt wird, trägt dieser Overhead in Kombination mit dem SSL-Verschlüsselungsoverhead zu den Verbindungskosten bei. Das ist zwar in der Regel keine große Bandbreite, kann aber erheblich sein, wenn Ihre Nutzlasten klein sind oder Sie häufig kurze Verbindungen herstellen.
- SSL-Verschlüsselungs-Overhead: Der Aufwand für die SSL-Verschlüsselung, der für sichere Verbindungen erforderlich ist, verursacht Kosten. Im Durchschnitt betragen diese Kosten etwa 3,5 KB für den anfänglichen Handshake und etwa 40 B für TLS-Eintragsheader in jeder ausgehenden Nachricht. Bei den meisten Apps ist dies ein kleiner Prozentsatz Ihrer Rechnung. Dies kann jedoch ein großer Prozentsatz werden, wenn Ihr spezieller Fall viele SSL-Handshakes erfordert. Geräte, die keine TLS-Sitzungstickets unterstützen, erfordern beispielsweise eine große Anzahl von SSL-Verbindungs-Handshakes.
Weitere Informationen zum Nachvollziehen und Schätzen Ihrer Rechnung