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.
Related
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.
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'm creating mobile application for iOS and Android. The problem is when any data has changed on server, I cannot notify mobile devices.
I have found 3 solutions, each have minus and pluses.
Use push notifications. Since iOS always shows a notification to user this is not a solution at all. Also I cannot know if the notification will go to device or when it will.
For every X seconds ask server if any change exists. I don't want to do that, because creating too many HTTP connections and closing them is not a good idea I think. Also if the data is changed right after the device asks, the info change on device will occur late.
Use web socket. My application's one time usage expectation is ~2 minutes. So web socket looks like a good choice, because app will be terminated or go to background state quickly and battery consume won't be much. Also all the server side data changes will come to the device just in time. But I don't know much about web socket. Is my opinion acceptable? Also how many concurrent connections can be done by my server. Is it a question too.
Here are my all solutions.
The document would suggest assumption 1. above is incorrect.
If you read the The Notification Payload section, you'll come across this;
The aps dictionary can also contain the content-available property. The content-available property with a value of 1 lets the remote notification act as a “silent” notification. When a silent notification arrives, iOS wakes up your app in the background so that you can get new data from your server or do background information processing. Users aren’t told about the new or changed information that results from a silent notification, but they can find out about it the next time they open your app.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
I think for the most part this depends on what your app is doing.
I would say you should use a combination of #1 and #2.
2 - At the very base level if you need information from the server you are going to have to make a request. If this information needs to be up to date then you can proceed to make a request for the information when the ViewController is loaded. If you need this information to update as the ViewController is loaded then you will need to make subsequent requests every X seconds... In addition to this if your user is interacting with this data and sending an update to the server you can check at this point if the data is up to date and alert the user as well as return the current data.
1 - Push Notifications operate off of the 'send and forget' protocol. The notification is sent and is not verified if it is received or not. This is used as a supplement to #2 and is 'nice' but should not be depended upon.
Push notification is the intended way (from both Google through Google Cloud Messaging, and Apple through Apple Push Notification Service).
Both option 2 and 3 are frowned upon as they affect battery life, and they are unnecessary as most cases scenarios can be covered by push notifications.
I just inherited an Android app project as a (technical) product manager that uses a 5 second timer to poll a remote URL to see if some work initiated by the app has finished. My initial reaction of course was to suggest to replace this with a push/notifications mechanism, preferably Android's built in GCM, so the work is removed from the app on the phone and put on the server side.
Surprisingly I met resistance from the development team. A former product manager (my predecessor) seems to have explicitly requested the implementation to work this way. Unfortunately, he wasn't big on documenting his decisions, so I now have to try to retrace which reasons could have led to this decision to justify a change in the implementation. I came up with the following pro and contra list:
Contra Push / Pro Poll
-
-
Server side work needed to implement push notifications
-
No direct way to know if push notification was successfully delivered
Scaling push notification delivery can be a pain
Pro Push / Contra Poll
Work is removed from device
Lower bandwith usage
Lower battery usage
More responsive application and device
Server load is lowered as devices don't poll every x seconds even if nothing changed (DDOS)
-
Push is faster (more responsive) than 5 seconds (current timer)
Delivery proof of push notification is trivial to implement with a poll of a remote URL (here it makes sense)
Scaling push notification delivery is a solved problem with lots of open source projects and trivial implementation with a message-queue
Are there any other reasons to avoid Push Notifications and use Polling for this usecase?
Are there any other reasons to avoid Polling and use Push Notifications for this usecase?
Any other important things I forgot?
No way to know if push notification was successfully delivered
Sure there is: have the device hit your server upon receipt of the push message. You might need to do that anyway, if the payload is bigger than 4K.
Scaling push notification delivery can be a pain
It works for fairly large user bases (e.g., RememberTheMilk), and that was even before the XMPP based persistent socket solution.
Are there any other reasons to avoid Push Notifications and use Polling for this usecase?
GCM has no service level guarantee. GCM is Android-specific; you might consider a wrapper around it, like Amazon SNS, if you are looking for something that will handle other client operating systems. Push solutions involving third parties, like Google, means that your raw push message payload will be visible to those third parties' servers; please use suitable app-level encryption if this is a concern (and it should be).
Are there any other reasons to avoid Polling and use Push Notifications for this usecase?
A five-second poll makes $BABY_DEITY cry.