Mit dem Datenbank-Profiler-Tool, das in der Firebase CLI integriert ist, 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 ein Profil erstellen zu können.
Starten Sie das Profiling Ihrer Datenbank mit dem folgenden Befehl:
firebase database:profile
Drücken Sie die Eingabetaste, um das Profil abzuschließen und die Ergebnisse anzuzeigen.
Ergebnisse auswerten
Das Profiler-Tool fasst die Daten zusammen, 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, das durch einen Schrägstrich/dargestellt wird. - 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 in der Warteschlange verbringen, bevor sie ausgeführt werden. 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 das Schreiben skaliert mit der Menge der geschriebenen Daten. |
| Ausführungsgeschwindigkeit von Connect | Die Serverantwortzeit für Anfragen an Datenbankclients. Die Latenz bei 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 Property Anzahl im Bericht zur Übertragungsgeschwindigkeit gibt die Anzahl der durchgeführten Übertragungen an, 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 am angegebenen Pfad ausgeführt wurden.
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 über Lese- und Übertragungsvorgänge verbraucht werden, die ü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 Byte angezeigt. |
Nicht indexierte Suchanfragen
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“ enthält die folgenden Eigenschaften:
- Pfad:Der Pfad in Ihrer Datenbank, unter 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 außerdem Kundeninformationen 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 Tool zum Erstellen von Profilen: Kein Abrechnungstool
Verwenden Sie das Tool zum Erstellen von Profilen nicht, 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 ist nicht für die Schätzung der Abrechnung gedacht. 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üsselungsoverhead:Für sichere Verbindungen ist ein SSL-Verschlüsselungsoverhead erforderlich, der mit Kosten verbunden ist. 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 einen großen Prozentsatz ausmachen, wenn in Ihrem Fall viele SSL-Handshakes erforderlich sind. Geräte, die keine TLS-Sitzungstickets unterstützen, erfordern beispielsweise eine große Anzahl von SSL-Verbindungs-Handshakes.