I subscribed 1.5 million users to topic TEST. I sent a message to TEST with a reach rate of only 10% to 20%. If I send it alone to 1.5 million users, the arrival rate will reach 40% to 60%. We think 40% ~ 60% are reasonable. Does FCM have any restrictions on the amount of delivery for topic messages?
Thanks
There is no limit on the number of devices that can subscribe to a topic. tThe only difference between using a topic and directly sending to the device IDs should be that topic delivery takes slightly longer due to the fan-out process.
As long as the devices have subscribed to the topics with their latest tokens/instance IDs, the delivery rates should be the same.
If this is not the case, it would be great if you can give clear steps to reproduce in the question. But I get that this may not be possible if the problem only happens at >1M registrations. In that case I recommend reaching out to Firebase support for personalized help in troubleshooting.
Related
We use the Sonos Control API to control the Sonos Speakers in a Smart Home System. Now we seem to have hit the rate limit for the requests sent to the API.
We get the error 429 Too Many Requests.
As described here https://developer.sonos.com/build/direct-control/control/ this means that we have hit the rate limit of the Sonos API. But there is no detailed information about the limits.
So I have the following questions:
How much requests are allowed until the rate limit is hit?
When is the rate limit being reset?
Is the rate limit per Integration or per Customer/IP?
At the moment we make a request per minute/per customer to get the groups, favorites, etc. We plan to change this behavior to use the subscriptions. But also if we use the subscription it would be good to know if we still could hit the rate limit if many customers make a request at the same time.
We generally don't rate limit unless we notice bad behavior. In that case, we manually rate limit or block clients at our discretion.
Consider using subscriptions instead of polling to monitor changes to groups and favorites.
I was not able to find any information about the maximum number of concurrent requests and maximum number of requests in one second to the Visual Recognition service.
Can you provide me with information or link where I can read about limits in general?
There is not a hard limit on concurrency per user. The service is designed to support many users simultaneously, and therefore has capacity to process many requests in parallel. During periods of heavy use however you may occasionally receive a 500 return code, in which case the request should be resubmitted.
Unfortunately there is a legacy error message in the system that tells users they may be submitting too many concurrent requests , but it is very unlikely that the error is actually caused by a users' concurrency. They should be treated like a 500 error code - just resubmit the request.
You should have no problem submitting 30 or 40 requests concurrently.
Standard API keys are limited to 25,000 events per day by default to prevent something like an infinite loop from generating a huge bill. You can have that limit increased by creating a bluemix support ticket. If you really want to do some large scale processing in parallel it would also make sense to get in touch with Support with a bluemix ticket so that we can guide you in the most cost effective and efficient way to use the service.
We use the free API for a simple 501C3's map. Usually our geo-coding usage is quite low, but a change we made [oops] triggered all >2500 records to re-request.
We can wait the 24H "timeout" imposed.
Our concern is will Google log this as abuse? Do we need to write code to cap our geocode usage at 2499/day in case of a future event?
Google doesn't consider daily over quota as abuse. You can trigger anti abuse systems in case if you are sending too many queries per second from the same IP address as far as I know, but if your QPS is within allowed 50 queries per second you should be OK. Daily quota is reset automatically, so you should just wait until 0:00 PDT when the reset is typically happen.
With the introduction of topics in android gcm I was evaluating this option to easen the work that should be done to mantain in sync our server with some subscriptions.
However I have read in the documentation that the use of topics is limited to 1 million subscriptions. Does this mean that you can't have more than one million users (with one or more topics) or that you can only have 1 million topics subscribed (for example 100.000 users subscribed to 10 topics each) ?
It's a limit on subscriptions in your app in total, across all topics created within your app.
You will get a TOO_MANY_SUBSCRIBERS error when the number of subscriptions per app exceeds the 1 million limit.
I think the limit has now been scrapped:
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app.
https://developers.google.com/cloud-messaging/topic-messaging
You could try to work around this limit by using multiple SENDER_IDs when registering devices.
Since the 1 million subscriptions limit is enforced application-wide, I'm pretty sure that Google's way of tracking that is via the SENDER_ID.
And then, on the server-side, you'd have to issue multiple publish requests to GCM (each time with a different Server API Key, to support more than 1 million devices).
I'm going to test this theory out and let you know what I find. The worst-case scenario is that it is enforced via the application's package name (com.example.package), and then there is no elegant workaround.
Update: The limit has now been removed!
We’re now happy to announce that we’re allowing unlimited free topics for your app. This means app developers can place an unlimited number of devices within each topic and create an unlimited number of topics.
http://googledevelopers.blogspot.co.il/2015/12/google-cloud-messaging-weve-come-long.html?utm_source=Android+Weekly&utm_campaign=1cb848077c-Android_Weekly_184&utm_medium=email&utm_term=0_4eb677ad19-1cb848077c-337844217
GCM now removed the limit, check this: https://developers.google.com/cloud-messaging/topic-messaging
Also Firebase Cloud Messaging (FCM) the same. https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app. The app server sends messages with payloads up
to 2KB to the topic, and GCM handles the message routing and delivers
the message reliably to the right devices. For example, users of a
weather forecasting app could opt in to a "severe weather alerts"
topic and receive notifications of storms threatening specified areas.
Topic messaging supports unlimited topics and subscriptions for each app.
Check This
[FCM Notifications][1]https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
Anybody know if there is any API call limits per second, hour or day for Tumblr API? It seems to me the limits do exist when I make a lot of api calls in a short period via OAuth. However, I couldn't find any document on Tumblr API website or on Google. Many thanks.
I have been using Tumblr API for about 2 years now, and I must admit that "Rate Limit Exceeded" issue has no deterministic and, more important, officially confirmed answer.
In Tumblr's API Agreement you may find some reference to limitations under section "Respect for Limitations" which says
In addition, you will comply with any limitations imposed by Tumblr on the frequency of access, calls and use of the Tumblr API and Tumblr Firehose
We ask that you respect these limitations, as well as any rate limits that we may place on actions, which are designed to protect our systems
Notes:
There is a special Tumblr tagged blog "rate-limit-exceeded" dedicated to this. However, it does not say much about number of request per period of time that a reported person used when facing this problem.
For example here you can find avg 1000 requests per minute to be the limit.
As for my application the request rate is approximately 1 request per second. The application runs for about a year already in 24/7 manner. There were several times though this issue occurred to me even with this relatively low rate. However, I consider the failure rate to be insignificant.
From: https://www.tumblr.com/oauth/apps
Newly registered consumers are rate limited to 1,000 requests per hour, and 5,000 requests per day.
If you go to that link it looks like you can get the rate limit removed if you ask nicely! :)