I am planning to use Google's FCM messaging for sending Real Time Alerts to my Tsunami Alerter app.
Wanted to know whether if there are 100,000 users of my app they would be able to receive instant alerts within say 3-5 minutes? (I heard FCM has limits) but I am still not able to comprehend what are those limits are!
Can anyone please explain me further? (100,000 messages to 100,000 different users within 5 minutes)
Whether Parallel connections limit like 1000 users will come into picture if I use a Free Plan?
Can anyone please explain me further? (100,000 messages to 100,000 different users within 5 minutes)
Typically you get a push message within seconds but of course there are other factors such as internet connection and device power profiles.
Whether Parallel connections limit like 1000 users will come into picture if I use a Free Plan?
There is no such thing as a "Free Plan" since FCM is free. Other Firebase services you have to pay for.
All the 1000 connections thing means is that you can send a max of 1000 messages in a single request so you have to split them up
Related
Our app with more than a million subscribers is facing huge delivery issues with FCM. It has become worse lately and the service is hardly working anymore. We are receiving errors like:
{ code: 'messaging/message-rate-exceeded',
message: 'Topic quota exceeded.' },
codePrefix: 'messaging' }
We get this error a lot. And it seems to be worse during EU / US evenings. In some cases over 90% of the notifications are failing.
We are in contact with the firebase support team, but so far there seems to be no solution. The gave us lots of information with some useful facts though:
resources are shared between developers. So the max message rate can be different because of other developers taking up resources.
OR queries should be converted to multiple AND queries because OR queries actually generate messages to all of user base, and then the filtering condition is applied
240 messages/minute and 5,000 messages/hour to a single device.
limit upstream messages at 15,000/minute per project (we don't understand this one)
limit upstream messages per device at 1,000/minute
They also updated their docs at https://firebase.google.com/docs/cloud-messaging/concept-options#topics_throttling
So we are aware of message rate limits and fanouts mechanism. In our case we have an approximate of 6000 different topic send requests per hour and on average 10k subscribers per topic.
A single user will never get more than 50-100 notifications per hour.
We believe we are not hitting the limits set by FCM.
Back in the GCM time everything worked fine. So we are quite unhappy about the current situation. The core functionality of the app is really bad right now. And a solution seems to be not there.
We are considering switching to a SSE solution.
There is a story about someone who succesfully moved away from FCM
https://f-droid.org/en/2018/09/03/replacing-gcm-in-tutanota.html
But since Google has made it very difficult lately to have background processes running, I wonder what other people with similar experience did.
Or can we still fix this situation?
One such alternative is Cloud Alert - it can replace FCM, provides high throughput and unlimited messages. It uses a background job and maintains its own connection to its dedicated servers. While a free plan is present, your 1 million connection requirement would put you into the paid bracket.
Disclosure: I work for Cloud Alert.
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.
I can't find documentation on best practices for the maximum number of messages one should send to the Firebase database (or one like it) over a period of time, like one second, and also what rate an app could handle receiving without slowing down significantly. For example:
//send updated location of user character in MMORG
MyDatabaseReference.child(LOCATIONS).child(charid).setValue . . .
//recieive locations of other characters in a MMORG
MyDatabaseReference.child(LOCATIONS).addValueEventListener(new
ValueEventListener() { . . .
In testing, 3 devices each sending 20 messages per second to the database, and each receiving 60 messages per second, appears to work OK (S8 used, a fast device). I was wondering what would happen with, say, 100 devices, in which case each user app would be getting 2000 messages per second theoretically. I imagine there is some automatic throttling of this.
As mentioned in Firebase officil documentation regarding Firebase database limits, there is a maximum of 1000 write operations/second for the free plan.
If you want to stay on the free plan, remember that when you'll reach the maximum number of writes per second, it doesn't mean that you'll not be able to use Firebase database anymore. When 1001th simultaneous connection occurs, a queue of operations is created and Firebase will wait until one connection is closed, and than it uses your new connection.
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.
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.