[FIREBASE CLOUD MESSAGING] [FCM] Topic sends and performance concerns

[Pasquale Puzio]

Hi all,

Our app is already in production but so far we've been using another push notification provider (OneSignal for the record), therefore right now we're still testing Firebase Cloud Messaging.

1) Based on a previous conversation with Firebase support, since our app has less than 1 Million users (around 700K to be precise), it shouldn't be a problem (in terms of quotas and latency) to send 1 topic message (to a topic containing around 500K users for instance) every few minutes. Is that true?

2) We send most of the time 1 large topic message (large means around 500K users) every about 30-60 minutes.

In some rare cases, we may need to send 4-5 large topic messages in 1 hour or so, plus a few other messages to small topics (small means 40-50K users subscribed).

In order to send topic messages, we leverage Python Firebase Admin SDK and we use either the "topic" parameter or a condition with a single topic, that is "'topicX' in topics".

Is there any difference in terms of performance and delivery if we use the topic parameter in the python Firebase Admin SDK or we use a condition with a single topic ('topicX' in topics)?

3) In some cases, we need to send messages to 2 topics (topicX and topicY for instance). Since using the OR operator has a negative performance impact, we're currently sending two messages with the following conditions:

- message 1: 'topicX' in topics

- message 2: 'topicY' in topics && !('topicX' in topics)

this is to avoid that a user subscribed to both topics will receive the same message twice.

Is this correct? is it better than sending only one message using the OR operator? What impact does it have in terms of delivery performance and quota?

4) when hitting quotas, does the Firebase API return an error after sending the message? Or will the application still see that the message has been successfully sent?

5) if instead of sending messages to topics we would target hundreds of thousands of registration tokens (meaning thousands of requests as a multicast message can only contain up to 100 registration tokens), will the same topic quota limitations still apply?

6) let's suppose we have thousands of topics with a few users each (let's say 10 users per topic), would we have any quota or latency issues if we sent a message to a single topic (meaning 10 users or less) every 4-5 seconds?

Thanks for your time.

[Ciaran Downey]

Hi Pasquale,

These are great questions. I've put my answers inline.

>1) Based on a previous conversation with Firebase support, since our app has less than 1 Million users (around 700K to be precise), it shouldn't be a problem (in terms of quotas and latency) to send 1 topic message (to a topic containing around 500K users for instance) every few minutes. Is that true?

It depends on how often "every few minutes" is. A fanout rate of 10,000 QPS for an individual project is not uncommon, but also not guaranteed. If you only have one topic fanout happening in your project then that seems like a reasonable expectation. The FCM docs have more detail.

>Is there any difference in terms of performance and delivery if we use the topic parameter in the python Firebase Admin SDK or we use a condition with a single topic ('topicX' in topics)?

Both should get optimized to the same thing, so it shouldn't matter.

>Is this correct? is it better than sending only one message using the OR operator? What impact does it have in terms of delivery performance and quota?

This approach has different performance characteristics compared to using a single topic send. The individual condition fanouts will exhibit a higher QPS than the single topic version would, but firing two at once will mean that the two are competing for project-wide resources.

>4) when hitting quotas, does the Firebase API return an error after sending the message? Or will the application still see that the message has been successfully sent?

Trying to exceed quota caps will in most cases cause errors, but hitting throttling limits will just delay the messages. Here's the relevant section from the docs:

"""
Message fanout is not instantaneous and so occasionally you have multiple fanouts in progress concurrently. We limit the number of concurrent message fanouts per project to 1,000. After that, we may reject additional fanout requests or defer the fanout of the requests until some of the already in progress fanouts complete.

"""

>5) if instead of sending messages to topics we would target hundreds of thousands of registration tokens (meaning thousands of requests as a multicast message can only contain up to 100 registration tokens), will the same topic quota limitations still apply?

The topic quota limits do not apply for multicast messages, though other limits discussed in the docs will still apply.

>6) let's suppose we have thousands of topics with a few users each (let's say 10 users per topic), would we have any quota or latency issues if we sent a message to a single topic (meaning 10 users or less) every 4-5 seconds?

If you're sending a single message to a single topic of <= 10 users, we wouldn't expect to see any large quota or latency issues. Sending a thousand messages each to a different topic will cause all the sends to compete with each other for QPS so you may see some latency issues.

Thanks,

Ciaran

[Pasquale Puzio]

Hi,

Thank you very much, I appreciate you took the time to answer my questions.

Just to make sure I got it right, are you saying that sending 2 messages with two following conditions:

- message 1: 'topicX' in topics

- message 2: 'topicY' in topics && !('topicX' in topics)

will probably achieve higher QPS than sending a single message with the OR operator? Of course they will share the project quota.

Thanks