Misura le prestazioni di Firebase Realtime Database con lo strumento Profiler di database, integrato nell'interfaccia a riga di comando di Firebase. Lo strumento Profiler registra tutta l'attività nel tuo database in un determinato periodo di tempo, quindi genera un report dettagliato. Utilizza il report dettagliato per risolvere i problemi relativi alle prestazioni del database, individuare le aree problematiche e ridurre le query non indicizzate.
Creare un profilo
Prima di iniziare a profilare il tuo Firebase Realtime Database, assicurati di utilizzare l'ultima versione della CLI Firebase e di averla inizializzata per il database e il progetto che vuoi profilare. Tieni presente che devi essere un editor o un proprietario del progetto per creare il profilo.
Avvia la profilazione del database con il seguente comando:
firebase database:profile
Premi Invio per completare il profilo e visualizzare i risultati.
Interpretare i risultati
Lo strumento di profilazione aggrega i dati raccolti sulle operazioni del database e mostra i risultati in tre categorie principali: velocità, larghezza di banda e query non indicizzate.
Velocità
Il report Velocità misura il tempo di risposta del server (in millisecondi) per ogni tipo di operazione. Tuttavia, la velocità misurata nel report sulla velocità potrebbe non riflettere effettivamente la velocità sperimentata dagli utenti finali. Diversi fattori, tra cui le condizioni di rete, possono aumentare la latenza sul lato client.
Il report sulla velocità include le seguenti proprietà:
- Percorso:il percorso nel database in cui si sono verificate le operazioni. Se
sono presenti più di 25 nodi secondari, lo strumento Profiler li comprime in un
percorso principale e aggiunge un marcatore
$wildcard. Nel report potresti visualizzare la directory principale del database, rappresentata da una barra/. - Conteggio:il numero di operazioni che si sono verificate nel percorso specificato.
- Velocità di esecuzione media:il tempo medio necessario al server per eseguire la logica di business necessaria per gestire il particolare tipo di operazione in quel percorso. L'intervallo di tempo misurato qui inizia dopo quello misurato dal "Tempo medio di attesa" descritto di seguito.
- Tempo medio di attesa:il tempo medio che le richieste trascorrono in coda prima di essere eseguite. Questo ritardo è comune a tutte le richieste avviate dal client. La latenza totale delle richieste lato server è approssimativamente la somma del tempo di attesa e della velocità di esecuzione della richiesta.
- Autorizzazione negata:il numero di operazioni nel percorso specificato bloccate dalle regole del database Firebase nel tuo database.
| Report velocità per tipo di operazione | |
|---|---|
| Velocità di esecuzione della lettura | Il tempo di risposta del server per le richieste del client di leggere i dati dal database. Il tempo di esecuzione della lettura in genere aumenta in proporzione alla quantità di dati letti, ma anche alcune piccole letture possono essere ritardate dal precaricamento della cache. |
| Velocità di esecuzione della scrittura | Il tempo di risposta del server per le richieste del client di scrivere dati nel database. Scrivi scale temporali di esecuzione con la quantità di dati scritti. |
| Velocità di esecuzione della connessione | Il tempo di risposta del server per le richieste di connessione ai client di database. La latenza per le richieste di connessione è dominata dalla contabilità lato server in memoria relativa alla gestione delle connessioni. |
| Velocità di esecuzione della trasmissione | Il tempo impiegato dal server per distribuire i dati ai client in ascolto del percorso specificato per gli aggiornamenti in tempo reale. La proprietà Conteggio nel report sulla velocità di trasmissione aggrega il numero di trasmissioni avvenute, non il numero di client che hanno ricevuto le informazioni. Ad esempio, se 10 client erano in ascolto a un determinato percorso e il server ha trasmesso un aggiornamento a tutti e 10 i client, il conteggio delle trasmissioni riflette solo 1 trasmissione, anche se 10 client hanno ricevuto i dati. La proprietà Autorizzazione negata non è inclusa nel report Velocità di trasmissione. |
Larghezza di banda
Il report Larghezza di banda fornisce informazioni sulla quantità di dati consumati dal database nelle operazioni in entrata e in uscita. Tuttavia, non devi utilizzare il report sulla larghezza di banda per stimare la fatturazione, perché non include la larghezza di banda utilizzata per altre operazioni, come la profilazione del database. Il report sulla larghezza di banda stima approssimativamente le dimensioni del payload dei dati utilizzati dalle operazioni di lettura, scrittura e trasmissione da e verso il database. È uno strumento che misura il rendimento, non uno che prevede la fatturazione.
Il report Larghezza di banda include le seguenti proprietà:
Percorso:il percorso nel database in cui si sono verificate le operazioni. Se sono presenti più di 25 nodi secondari, lo strumento Profiler li comprime in un percorso principale.
Totale:il totale dei byte in uscita o in entrata utilizzati in tutte le operazioni nel percorso specificato.
Conteggio:il numero di operazioni che si sono verificate nel percorso specificato.
Media:il numero medio di byte scaricati o caricati nelle operazioni nel percorso specificato (byte/scrittura o byte/lettura).
| Report sulla larghezza di banda | |
|---|---|
| Byte scaricati | Dati utilizzati tramite operazioni di lettura e trasmissione inviate tramite gli SDK client e l'API REST. |
| Byte caricati | Dati utilizzati tramite le richieste di scrittura in entrata nel server di database. Le eliminazioni vengono visualizzate come scritture con 0 byte in In entrata. |
Query non indicizzate
Le query non indicizzate possono essere costose, perché i client scaricano tutti i dati in una posizione ed eseguono query su di essi. In questo modo viene utilizzata più larghezza di banda del necessario. Risolvi il maggior numero possibile di query non indicizzate per ottimizzare le prestazioni del database.
Il report Query non indicizzate mostra le seguenti proprietà:
- Percorso:il percorso nel database in cui si sono verificate le query non indicizzate.
- Indice:la regola da aggiungere per risolvere il problema delle query non indicizzate. Scopri di più sull'indicizzazione in Indicizzare i dati.
- Conteggio:il numero di query non indicizzate che si sono verificate nel percorso specificato.
Profilazione avanzata
Per visualizzare tutte le operazioni gestite dal database, utilizza il flag --raw
quando profili il database, come segue:
firebase database:profile --raw
L'output non elaborato include anche le informazioni sul cliente per ogni operazione, ad esempio
stringhe userAgent e indirizzi IP. Scopri di più sulle diverse operazioni
profilate in Firebase Realtime Database in Firebase Realtime Database Tipi di operazioni.
Lo strumento Profiler: non è uno strumento di fatturazione
Non utilizzare lo strumento Profiler per stimare il costo della larghezza di banda. Lo strumento Profiler ha lo scopo di fornire un quadro generale delle prestazioni del database, per aiutarti a monitorare le operazioni e risolvere i problemi, non per stimare la fatturazione. Non tiene conto del traffico di rete, ma registra solo una stima dei dati dell'applicazione inviati nelle risposte.
Di seguito sono riportati alcuni esempi comuni di traffico di rete fatturato da Firebase che non sono coperti nel profilo del database:
- Overhead del protocollo: per stabilire e mantenere una sessione è necessario un traffico aggiuntivo tra il server e i client. A seconda del protocollo sottostante, questo traffico potrebbe includere: overhead del protocollo in tempo reale di Firebase Realtime Database, overhead WebSocket e overhead dell'intestazione HTTP. Ogni volta che viene stabilita una connessione, questo overhead, combinato con qualsiasi overhead di crittografia SSL, contribuisce ai costi di connessione. Anche se in genere non si tratta di una quantità elevata di larghezza di banda, può essere sostanziale se i payload sono piccoli o se effettui connessioni brevi e frequenti.
- Overhead della crittografia SSL:esiste un costo associato all'overhead della crittografia SSL necessario per le connessioni sicure. In media, questo costo è di circa 3, 5 KB per l'handshake iniziale e di circa 40 B per le intestazioni dei record TLS su ogni messaggio in uscita. Per la maggior parte delle app, si tratta di una piccola percentuale della fattura. Tuttavia, questa percentuale potrebbe aumentare notevolmente se il tuo caso specifico richiede molti handshake SSL. Ad esempio, i dispositivi che non supportano i ticket di sessione TLS potrebbero richiedere un numero elevato di handshake di connessione SSL.
Scopri di più su come comprendere e stimare la fattura.