Monitor Database Performance

There are a few different ways to monitor your Firebase Realtime Database's performance and spot potential problems in your app. Looking at your app's incoming and outgoing bandwidth and load can also give you an idea of what to expect on your bill. Additionally, if something seems off, getting a clear picture of your database's operations can be a helpful troubleshooting tool.

Use Realtime Database monitoring tools

You can gather data about your Realtime Database's performance through a few different tools, depending on the level of granularity you need.

Use the Realtime Database profiler tool

The Realtime Database profiler tool provides a realtime overview of read/write operations on your database. The report includes information about the speed and payload size of each operation, in addition to unindexed queries. It doesn't include historical information or any statistics about connection overhead, however, and should not be used to estimate billing costs.

To learn more about using the profiler tool, see Profile your database.

Use the Firebase console

The Usage tab in the Firebase console offers information about simultaneous connections to your database, how much data you're storing, outgoing bandwidth (including protocol and encryption overhead), and your database's load over 1-minute intervals. While the Usage tab gives you a more accurate overview of your database's overall performance, you might not be able to drill down enough to troubleshoot potential performance or billing issues.

Learn more about Usage statistics in the Firebase console in Estimate your billed usage.

Use Stackdriver Monitoring

With Stackdriver Monitoring from Google Cloud Platform, you can use the Metrics Explorer to see individual performance metrics, or create different dashboards with charts that display various combinations of performance metrics over time. The Realtime Database integration with Stackdriver Monitoring offers the deepest level of granularity.

To get started with Stackdriver Monitoring, follow the steps in the Quickstart for Google Compute Engine.

Once you've set up Stackdriver Monitoring, use the Metrics Explorer or create a dashboard with charts to monitor your database's performance.

The full list of Realtime Database performance metrics available through Stackdriver Monitoring is included in the GCP metrics list. See the following sections for tips on using specific metrics to spot billing or performance issues.

Monitor billed usage

Both the Usage tab in the Firebase console and the metrics available through Stackdriver Monitoring can help you estimate your billed Realtime Database usage. Keep in mind, however, that the usage statistics available in the Firebase console and through Stackdriver are estimates only. See Understand Realtime Database billing for more information about billing.

To use Stackdriver Monitoring to monitor your billed usage, track the following metrics:

• network/sent_payload_bytes_count: This metric reflects the size of the data requested through database operations (including gets, queries, writes, realtime listener updates, and broadcasts). It does not include any connection overhead (protocol or encryption). The sent_payload_bytes_count contributes to your outgoing bandwidth costs, but it doesn't account for the total billed costs. It's an estimate to the data sent from your database in response to requests, but, since it measure the payload size of the data requested, not the data actually sent, it may not always be accurate.
• network/sent_payload_and_protocol_bytes_count: This metric reflects the size of both the payload data described above and the protocol overhead necessitated by the connection (for example, HTTP headers, WebSocket frames, and Firebase realtime protocol frames). It doesn't account for encryption costs on secure connections.

• network/sent_bytes_count: This metric reflects an estimate of the total size of data sent out from your database through reads. It includes the payload data that is actually sent to clients, in addition to the protocol and encryption overhead that results in connection costs. This most accurately reflects the total outgoing bandwidth on your Realtime Database bill.

• storage/total_bytes: Use this metric to monitor how much data you're storing in your database. Data you store in Realtime Database contributes to your billing costs.

Combine metrics in charts on your dashboard for helpful insights and overviews. For example, try the following combinations:

• Outgoing data: Use the network/sent_bytes_count, network/sent_payload_and_protocol_bytes_count, and network/sent_payload_bytes_count metrics to spot potential issues with protocol or encryption overhead contributing to unexpected costs on your bill. If you see a large discrepancy between the size of the data payloads requested and the other metrics reflecting connection overhead, you might want to troubleshoot issues that might be leading to timeouts or frequent connections. If you're not using TLS session tickets, you might try implementing them to reduce SSL connection overhead for resumed connections.
• Operations: Use the io/database_load metric to see how much of your total database load is used by each operation type. Make sure to group io/database_load by type to troubleshoot different operation types.
• Storage: Use the storage/limit and storage/total_bytes to monitor your storage utilization in relation to the Realtime Database storage limits.

See the full list of Realtime Database metrics available through Stackdriver Monitoring.

Monitor performance

If you're experience issues with performance, including uptime or latency, you might want to use Stackdriver to monitor the following metrics:

• io/database_load: Use this metric to monitor how much of your available database bandwidth is in use processing requests over time. You might see performance issues as your database load approaches the total available bandwidth. You can also see which operation types are utilizing the most load, and troubleshoot accordingly. Reported load might exceed 100% on operations that take longer than a minute. This happens when the total bandwidth used across multiple minutes is condensed into the minute-long reporting interval after the operation has completed.
• network/disabled_for_overages: This metric reflects any outages that might have occurred if your Realtime Database exceeded any bandwidth or network limits.
• storage/disabled_for_overages: This metric reflects any outages that might have occurred if your Realtime Database exceeded any storage limits.

Combine metrics in charts on your dashboard for helpful insights and overviews. For example, try the following combinations:

• Operations: Use the io/database_load metric to see how much of your total database load is used by each operation type. Make sure to group io/database_load by type to troubleshoot different operation types.
• Storage: Use the storage/limit and storage/total_bytes to monitor your storage utilization in relation to the Realtime Database storage limits. You can also add storage/disabled_for_overages to see if your app experienced any down time as a result of exceeded storage limits.
• SSL overhead: Use network/https_requests_count to monitor how many SSL connection requests your database received, and split out requests that reused an existing SSL session ticket with the reused_ssl_session filter. You can measure this against the network/sent_bytes_count and network/sent_payload_and_protocol_bytes_count to monitor whether or not your app is using SSL session tickets efficiently.

You can also set up alerts through Stackdriver Monitoring and receive notifications based on Realtime Database metrics. For example, you can choose to receive a notification if your io/database_load is approaching a certain threshold.

See the full list of Realtime Database metrics available through Stackdriver Monitoring.

Database Load Types

The io/database_load metric also provides a label of which operation type caused the load. The following are the possible types of operations measured:

• admin: Admin operations like setting rules and reading project metadata.
• auth: Verifying authentication from service accounts or Firebase Authentication for a single client.
• client_management: Handling the addition and removal of concurrent connections this includes running disconnect operations on removal.
• get_shallow: Retrieving the data from a REST GET with shallow=true.
• get: Handling REST GET operations.
• listen: Retrieving the initial data for on and once operations from connected clients.
• on_disconnect: Registering on disconnect operations from clients.
• put: Handling set operations from clients or REST PUT operations.
• transaction: Performing transactions from conditional REST requests or a transaction operation from a client.
• update: Handling update operations or REST PATCH requests.