After reading this thread I still not very clear.
I use Candle plan for my example.
If every user in my app have 1 browser tab open mean I can only have 200 users in the same time?
If you're running the free plan, firebase will cut you off at 50 connections. This means, user 51 will be unable to connect to firebase. Or, if you open 50 tabs that are all identified as unique firebase connections, tab 51 will not connect.
If you're using any paid plan, your connections will expand and scale automatically, this means that users will never be cut off.
"Because we use 95th percentile billing, you won't be charged for your overages 5% of the time (about 1.5 days each month). If you exceed your limits for more than 5% of the month, the following overage fees will be added to the base price of your monthly bill:"
So, even if you exceed your number of active connections, it will not count for billing unless the number of active connections exceeded your maximum for over 5% of the time covered in the billing period.
Any paid plan will never be cut off (as long as you continue to pay your bills and overages!) so you can have more than 200 users simultaneously!
Source: Firebase
Related
Azure Cosmos DB free tier give us 1000 RU/s and 25 GB of storage.
I created a database with one container, added some data to it and executed some queries.
Looking at the insights, I can see this:
Does that mean I used 99.68 RUs out of the 1000 RUs from the free tier?
Are those 1000 RUs in a month?
Does that mean I used 99.68 RUs out of the 1000 RUs from the free
tier?
It means that you used 99.68 request units in total. It is unclear over what time period you used these but even if that was all in one second this is well within the 1,000 RU/S limit.
Are those 1000 RUs in a month?
No. When you remember that RU/s is "Request Units per Second" this doesn't make sense. It is an ongoing allowance and based on RU provisioned (whether manually or via auto scale) not RU used.
I imagine that you may be concerned that you have already used 10% of your free allowance? This is absolutely not the case. For a container provisioned at 1,000 RU/s you can use 1,000 RU for each second and the allowance starts fresh each second. Any historic request units used have no importance here.
In terms of actual request units the free account means that potentially you could use 2,592,000,000 per month without paying any extra if you were somehow able to keep the collection constantly processing operations worth 1,000 request units every second in that month.
If you exceed the limits for the free tier by provisioning more than 1,000 RU/s you will be billed accordingly at hour granularity.
With the free account if you want to be certain to avoid additional charges you should currently steer clear of autoscale. The minimum autoscale range that can be configured is now 100-1,000 RU/s (was previously 400-4,000) - but autoscaled RUs are charged at a 50% premium so 1,000 autoscaled RU/s is billed as 1,500.
With the free account you can provision without charge up to 1,000 RU/s via fixed provisioning across all containers and databases in the account - with fixed provisioning you are charged based on what you provisioned rather than what you used (the system will throttle you if your usage would exceed provisioned limit).
Firebase Analytics reports data w.r.t. Daily/Weekly/Monthly Active Users.
Few questions:
(1) Dashboard:
Projecting the Daily Active Users to a month, does not match the value shown in Firebase Dashboard.
For e.g. if Daily Active Users is 30K, then Firebase shows the corresponding Monthly Active Users as 150K.
Does it imply that there were 30K users in last 7 days, and 120K in the preceding 21days?
Not sure why isn't it 30 days x 30K = 900K.
(2) On selecting Firebase > Events > Select_Content > App version
Last 7 days: shows approx 100K
Last 30 days: shows approx 140K
Does it imply that in the 21 day period only 40K User sessions occurred, while the App usage went up drastically in last 7 days?
Please help clarify.
thanks in advance,
The Active Users report in the Firebase dashboard is showing counts of users in the past 30, 7 and 1 day. The values are not projected, but rather based on user engagement that has been measured over those periods. The other thing to keep in mind is for each of those periods, it's the count of unique users over the entire period.
So, for example, if your seeing 150K Monthly Active Users (which is defined here as 30-day active users), that tells you you've had 150K unique users engage with your App in the last 30-day period. If you're seeing 30K Daily Active users, that tells you you had 30K unique users yesterday, and 120K different unique users from the 29 days before yesterday.
If the same user engages with your App more than once in the period, they only count as one. Out of your 30K users from yesterday, a number of those would have presumably engaged in the 29 days before that, so it's expected that your Monthly Active Users would be less than your Daily Active Users x 30 days. How much lower would depend on the specifics of your app, but the closer those numbers are, the more frequently the same users are returning to your App over the 30 days, which is positive in terms of user engagement retention.
I'm testing out the Here API for geocoding purposes. Currently in the evaluation period, some of my tests include geocoding as many as 400 addresses at a time (later I may rarely hit 1000). When I tried this with google maps, they would give me an error indicating I'd gone over the rate limit, but I have not gotten such an error from Here API despite not limiting the rate of my requests (beyond waiting for one to finish before sending the next).
But in the Developer FAQ the Requests Per Second limit is given as:
Public Plans Business Plans
Basic 1 N/A
Starter 1 1
Standard 2 2
Pro 3 3
Which seems ridiculously slow. 1 request per second? 3 per second on the highest plan? Is this chart a typo? If so, what are the actual limits? If not, what kind of error should I expect if I exceed that limit?
Their documentation states that the RPS means "for each Application the number of Requests per second to HERE Services calculated as an average (number of Requests during a period of 5 minutes) to all of the APIs used to access the features listed for each subscription plan".*
They say later in the documentation that quota is calculated monthly: "When a usage record is loaded into our billing system that results in a plan crossing its monthly quota, the price applied to that usage record is pro-rated to account for the portion that is included in your monthly quota for free and the portion that is billable. Subsequent usage records above your monthly quota will show at the per transaction prices listed on this website."*
Overages are billed at 200/$1 USD for Business or 2000/$1 USD for Public plans. So for the Pro plan, you will hit your limit if you use more than 7.779 million API requests in any given month, any usage beyond that would be billed at the rates above.
Excerpts taken from Developer FAQ linked above.
When using https://www.linkedin.com/countserv/count/share?format=json&url= to access an article's sharecount, is there an api daily limit?
We noticed that the time it was taking to retrieve count data was taking as much as 20 seconds on our production server. We added logic to cache the number of counts, and the 20 second delay stopped the next day. We are left wondering though what the limit might be (we can't seem to find it in your documentation).
Background:
I have a Google Analytics account using which I am tracking user activity for web and mobile app. After logging into your account and choosing the web property and the corresponding view, you generally see a dashboard with quick stats like Pageviews, Users, Sessions, Pages/Sessions, Avg. Session Duration, Bounce Rate and percentage of new sessions. You can change the time period (from the top right area of the Dashboard) to get the same stats for that period.
Problem:
Last week, I was interested in the three main stats: Page views, Users and Sessions for a particular day - say, day A. The dashboard showed the following stats:
Pageviews - 1,660,137
Users - 496,068
Sessions - 983,549
This report was based on 100% of sessions.
I go back to the dashboard TODAY and check the same stats for the same day A. Here's what I saw:
Pageviews - 1,660,137
Users - 511,071
Sessions - 1,005,517
This report is also based on 100% of sessions.
Nothing was changed in the tracking code for the web and mobile app. Could someone explain why I have this difference in the stats? Is this normal?
They need some time to update the system, otherwise their system would overwhelm
When you first create a profile it can take up to 48 -72 hours for it to start showing data.
After that time data will appear instantly in the Real-time reports.
Standard reports take longer to finish processing. You need to remember the amount of data that is being processed. Some of the data may appear in the standard reports after a few hours. The numbers have not completed processing for at least 24 hours, so anything you look at then will not be accurate.
When checking Google Analytics never look at todays or yesterdays numbers in the standards reports, if you want accurate information. Things get even more confusing when you consider time zones. When exactly is it yesterday? I have noticed numbers changing as far back as 48 hours. But Google Says in there documentation 24 hours. I am looking for the link in the documentation will post it when I find it.
Found it: Data Limits
Data processing latency
Processing latency is 24-48 hours. Standard accounts that send more
than 200,000 sessions per day to Google Analytics will result in the
reports being refreshed only once a day. This can delay updates to
reports and metrics for up to two days. To restore intra-day
processing, reduce the number of sessions you send to < 200,000 per
day. For Premium accounts, this limit is extended to 2 billion hits
per month.
So try doing the same thing again today but check your last day being Monday. When you check again next week the numbers should be correct.