CODEWITHSUNDEEP
javascriptfirebasegoogle-cloud-platformgoogle-cloud-firestore
CentoKili53
CentoKili53

Reputation: 133

Does query size affect Firestore snapshot listeners' performance?

I have 3 active Firestore snapshot listeners in my app, each of which listens to changes inside a different collection (not documents, but the whole collection).

At the moment, the collections' sizes are small but could get considerably bigger in the future, so would that affect performance at all, or does the size of the collection not matter?

I know there shouldn't be more than 100 active snapshots at a time, and that it's not a good idea to keep connecting and disconnecting the listeners frequently, but couldn't find anything on the actual size of the document/collection to which the listener is attached...

Upvotes: 0

Views: 731

Answers (2)

Alex Mamo
Alex Mamo

Reputation: 1

At the moment, the collections' sizes are small, but could get considerably bigger in the future, so would that affect performance at all, or does the size of the collection not matter?

The size of the collection doesn't matter at all. What matters, is the number of documents that are returned by your queries. Unlike in a SQL database, where the speed of the queries depends on the number of records that exist in a table, in Firestore the things are different.

The query performance in Firestore depends on the number of documents you request and not on the number of documents you search. It doesn't really matter if you search 10 documents in a collection of 1000 documents or in a collection that contains 100 MIL documents, the response time will always be the same.

That being said, if you'll query the database without a limitation, and the number of the documents that are returned by your queries will grow, then you might get slower queries. In that case, you should always consider getting data in smaller chunks. This technique is also called pagination.

I know there shouldn't be more than 100 active snapshots at a time.

There is no limitation to that. Listeners are cheap. However, if you are listening for real-time changes, you always consider removing the listeners according to the state of your app.

Couldn't find anything on the actual size of the document/collection to which the listener is attached.

As I already mentioned, the size of the collection doesn't matter when it comes to getting data. The number of documents that are returned matters. Regarding the size of the document, the maximum size of a document is 1 Mib. This doesn't count in terms of performance, as the query will take the exact amount of time, but it will take in terms of downloading the data.

Upvotes: 1

Tarik Huber
Tarik Huber

Reputation: 7418

The thing that could make a performance issue is not the size of the queries but the number of changes in a period of time. If you have 3 collections with 1000 documents where every 2 min some document changes that won't be a big performance deal but if you have 3 collections/queries with 100 documents but they have updates to a lot of them in every few seconds you will notice. Especially if you have state management that is syncing the data between Firebase and the state.

I would detach listeners in queries that get very often updates and leave them for those that stay the same for a while but could get updates. For example in applications with dropdown lists that is a common cause. They often stay the same but could get updates so we listen to them.

Also just to make it clear. The initial loading would of course take longer for each of them if they get larger in size but that should be obvious. Because of the great offline work of Firestore that will only be noticeable on the very first load and later on the user will get the data from cache and then from the server so he won't notice it.

Upvotes: 2

Related Questions