0

I am experiencing an unexpected number of reads from a react native app that uses google cloud firestore as a database. Perhaps my interpretation of reads is wrong so I will start with what I have learned from the Google docs and is relevant for my app:

  • a read is one doc that is updated or added. If you use a listener only newly or updated docs are calculated as a read.
  • a connection that becomes active after about 35 minute will receive all the reads from the listeners again ( i have read this somewhere in the docs). Not sure about:
    • Only active connections will receive new or updated docs from the listener.
    • An app that is in the background is not an active connection.

The problem:

When I am monitoring the usage of firestore I see for example one active connection, but cumulative 400 reads. Which are way more then the number of docs the combined listeners can receive. The monitor shows the correct number of active listeners in combination with the number of active connections. So 2 active connections show 10 listeners.

The architecture of my app:

  • 5 listeners per user that are called in the ComponentDidMount of the homepage of the app.I use props or redux state management to pass the data to other components. The 5 listeners are used during the lifetime of the app.
  • I use react navigation which means that the ComponentDidMount of the homepage is called once, because it is already on the stack. I think this will prevent the listeners in the homepage from being called multiple times.

Perhaps this can cause unexpected reads?

The only time the componentDidmount is called multiple times is when a user terminates the app. In that case the listeners are not unsubscribed. When the user starts the app again, the app sees that the user is still logged in and will reroute the user to the homepage instead of the login page. This could mean that the previous listeners of the terminated session are still active and will affect the number of reads? During monitoring I did not see an unusual number of active listeners though.

My Questions:

  • What can cause the unexpected number of reads considering the architecture of my app?
  • Is there a way to get more insight information about what actions trigger realtime listener reads in the app? I already use stackdriver and the default monitoring tool from firestore.

I am also seeing 1 k reads with no active connection and no other changes that have been made to the database:

1 k reads with no active connectioncluld also cause the problem?

Bert
  • 43
  • 7
  • 1
    The most common source of unexpected reads comes from the Firebase console itself while it is open on a collection whose documents are changing. Without seeing your specific code or explicit reproduction steps, there's not much we can say. There are currently no auditing tools for Firestore reads. – Doug Stevenson Jan 12 '20 at 17:54
  • Answering 'Perhaps this can cause unexpected reads? ' would be helpful. – Bert Jan 12 '20 at 18:04
  • I suggest asking a new more specific question on this one point that shows the code I question. – Doug Stevenson Jan 12 '20 at 18:06
  • I will do that. But also please have a look at this screenshot. 1k reads with no active connection. Is that the same problem you referenced to? – Bert Jan 13 '20 at 09:15

0 Answers0