How many push notifications can we send in Android in a single query and how much time does that query takes to deliver those push notifications
as you may read here:
https://firebase.google.com/docs/cloud-messaging/concept-options#device_throttling
You can send up to 240 messages/minute and 5,000 messages/hour to a single device. This high threshold is meant to allow for short term bursts of traffic, such as when users are interacting rapidly over chat. This limit prevents errors in sending logic from inadvertently draining the battery on a device.
Caution: Do not routinely send messages near this maximum rate. This could waste end users’ resources, and your app may be marked as abusive.
--
deliveries depend on your TTL for messages you set when you are sending. normally if everything is okay it should be delivered instantly.
Related
The FCM documentation about "multiple senders" declares:
Note that there is limit of 100 multiple senders.
However, I don't understand what will happen, if I'll try to send FCM message from, for example, 150 senders at the same time (i.e. all of them will use the same FCM token value for the message content).
Currently I have 3 suggestions for this case:
100 most "first" sendings will be successful, and remaining 50 sendings just will be postponed (and executed after finish of previous 100 sendings).
100 sendings will be successful, however remaining 50 sendings will be not executed in general.
All 150 sendings will be not executed.
What suggestion is correct?
The note is under the Receiving messages from multiple senders section. This pertains to actual senders, not messages. As pointed out in the docs, a specific app can receive messages from multiple sources.
None of the three suggestions apply to the statement, but here's an example:
Say you have a news app where you get to choose from multiple sources. All of the selected sources can send updates(push notifications) towards your app. However, you have a limit of 100 sources. You can't go beyond that. You have to free up space first by removing a source.
For messages however, the most likely error that'd you would receive when a specific device is receiving too much at a given rate is Device Message Rate Exceeded:
The rate of messages to a particular device is too high. If an iOS app sends messages at a rate exceeding APNs limits, it may receive this error message
Reduce the number of messages sent to this device and use exponential backoff to retry sending.
We are planning to implement Topic Messaging via FCM to send PN to our base, I want to know how much time FCM takes to deliver PN to apps via topic:
with 10 million subscribed to a topic
with 50 million subscribed to a topic
with 100 million subscribed to a topic
I understand delivery will depend on apps being online, however we can assume here hypothetical case of every one being online. In other words, I want to understand how does FCM processes sending PN to a topic and how much delay it will/might introduce?
The messages are enqueue and they will be deliver user by user from Firebase cloud messaging server, you can know the status of those messages at your Firebase Notifications console.
https://firebase.google.com/docs/cloud-messaging/understand-delivery
This video ensures that 95% of your messages will deliver with an average time of 250ms
https://youtu.be/sioEY4tWmLI
From this documentation
Maximum payload for both message types is 4KB, except when sending messages from the Firebase console, which enforces a 1024 character limit.
Another important thing you can find at this documentation
FCM does not guarantee the order of delivery.
Throttling and scaling
Our goal is to always deliver every message sent via FCM. However,
delivering every message sometimes results in a poor overall user
experience. In other cases, we need to provide boundaries to ensure
that FCM provides a scalable service for all senders.
Maximum message rate to a single device
You can send up to 240 messages/minute and 5,000 messages/hour to a
single device. This high threshold is meant to allow for short term
bursts of traffic, such as when users are interacting rapidly over
chat. This limit prevents errors in sending logic from inadvertently
draining the battery on a device.
Upstream message limit
We limit upstream messages at 1,500,000/minute per project to avoid
overloading upstream destination servers.
We limit upstream messages per device at 1,000/minute to protect
against battery drain from bad app behavior.
Fanout throttling
Message fanout is the process of sending a message to multiple
devices, such as when you target topics and groups, or use the
Notifications composer in the Firebase console.
We limit the number of in-progress message fanouts per project to
1,000. After that, we may reject additional fanout requests until some
of the fanouts complete.
The actual achievable fanout rate is influenced by the number of
projects requesting fanouts at the same time. A fanout rate of 10,000
QPS for an individual project is not uncommon, but that number is not
a guarantee and is a result of the total load on the system. It is
important to note that the available fanout capacity is divided among
projects and not across fanout requests. So, if your project has two
fanouts in progress, then each fanout will only see half of the
available fanout rate. The recommended way to maximize your fanout
speed is to only have one active fanout in progress at a time.
If you need more information, you can find it at those links I provide.
According to the following answers:
How long does it take for a message from Google Cloud Messaging to arrive on device
GCM - How long does it take for push notifications to reach the device?
The push notification should appear instantly when delivered, but you need to take into account the internet connection of the user.
It's simpl question. I don't need code examples or somethings.
Can I send a data message from my backend every 5 minutes? Is there a Google rules forbidding it?
Are there any limits for sending notifications?
I searched on the firebase site, but I could not find anything about the restrictions.
Well there is no rule which restricts you to send the FCM push so frequently. What would impact is the ability of receiving push by your app.
With introduction of doze mode, Google has placed several restrictions on how freely you can perform background processing. Although high priority FCM messages are delivered even during doze mode, but if they don't end up in user interaction they will be deferred.
Based on documentation:
High priority messages generally should result in user interaction
with your app. If FCM detects a pattern in which they don't, your
messages may be de-prioritized.
Android P comes up with priority buckets. If your app falls in Rare bucket, then high priority notifications drops to a limit of 5 a day.
I am using GCM to sync data across all user devices. When there is new data, generated by one of the devices, the server(RESTful API) sends a push to the rest, and each of them downloads the new data and updates the UI. The problem is that Google throttles my notifications when there are lots of changes(like 40 per minute = 40 pushed per minute per device) and the devices stop receiving new messages for a day or two. I read a lot about the topic and found that I should set time to live to 0 and delay while idle to false, but throttling still occurs.
So my question is, is it possible to disable GCM throttling and how could you recommend me to implement the whole sync process with RESTful backend?
As far as I know, you cannot disable throttling. It is a function performed by GCM and one of its uses is to preserve device battery life. In your case, 40 pushed messages per minute doesn't sound very efficient - you may want to consider whether you should compound those messages into fewer messages.
Or, use collapse key to collapse all these messages that are in transit, as suggested by #ianhanniballake.
If multiple PUSH messages are sent to the same device, then how is the queuing working in GCM.
This is covered in the documentation, should you wish to read it: http://developer.android.com/guide/google/gcm/adv.html#collapsible
Note: There is a limit on how many messages can be stored without collapsing. That limit is currently 100. If the limit is reached, all stored messages are discarded. Then when the device is back online, it receives a special message indicating that the limit was reached. The application can then handle the situation properly, typically by requesting a full sync.