I couldn't figure out a very strange thing that i see in the Instagram and Twitter API limits.
It seems that your user base can't exceed a very LOW limit, and than your app will just be blocked because limits are per app .
Instagram :
Per app, you have 5000 requests per hour(Auth/or not) .
see here : http://instagram.com/developer/limits/
That means if my app created in instagram,which has client ID, is making a call on behalf of a mobile user- that will be counted as 1 call -so i can't have more than 5000 users per hour using my app with my client id ??
Twitter
from the API limit doc :
If user A launches application Z, and app Z makes 10 calls to user A’s
mention timeline in a 15 minute window, then app Z has 5 calls left to
make for that window
can find here: https://dev.twitter.com/rest/public/rate-limiting
That means that if i created an app in Twitter, and my mobile user request his time line, so i can only have 15 active users in 15 minutes ?
I dont know if i miss something big here, or that the whole API is just worthless, you can't do anything big(or medium) with 15 users in 15 minutes, or even 5000 users per hour.
I think you misinterpret things...
Instagram is stating
Authenticated Calls: 5,000 / hour per token
Unauthenticated Calls 5,000 / hour per application
As you normally will HAVE to use authenticated calls to get user information, I think 5000 per Access Token (User) per hour should be more than enough.
Twitter is stating that
Rate limiting in version 1.1 of the API is primarily considered on a per-user basis — or more accurately described, per access token in your control. If a method allows for 15 requests per rate limit window, then it allows you to make 15 requests per window per leveraged access token.
The rate window is considered as 15min. This doesn't mean that you can only make 15 requests per Access Token in 15min, but e.g. 15 requests to GET account/settings per Access Token per 15min. See
https://dev.twitter.com/rest/public/rate-limits
Related
I'm looking for ways to overcome API quotas without resorting to requesting a raise, and would like to know what is classified as .. per user.
For example:
Google People API has this quota: Read Requests per 100 seconds per user
I setup an OAuth Client ID: 123-5ampl3.apps.googleusercontent.com
And for whatever reason, my queries are going to exceed "100 seconds per user".
My question/concerns:
Can I create another client ID 123-an0th3r.apps.googleusercontent.com and have both call the same API so that I now essentially have requests per 200 seconds per user?
Or is per user not tied to the client IDs, but instead, to the project id.
Could I create another project and re-route extra API calls to there?
Or must I throttle my querying so it stays within the limit.
Thanks!
I was asked to make a chat application on django for a special portal where only at a particular time 4 staff users can be talking to 4 selected users from a large (around 500 not all logged in at the same time) user database.
I implemented it using django and ajax with the following details ->
I used the chat model which stores all the chat messages sent to the server till now.Its fields are
userto
userfrom
message
Each user has two states :
He can wait for a chat room to get empty which he can be alloted
He can be in a chat room and talk with one of the staff users
When in a chat room , using ajax I query all messages in the chat table, and show the messages which belong to the chat. Now a request is sent to the server each 0.5 seconds to update the message list.
Note - Inside a chatroom only the messages between the two users should be displayed
When not in a chat room , The user is redirected to a normal page (which is not real time) and displays all chat rooms that can be joined.
Here the user refreshes the page and only at that time sends the request to the server , which updates the list of the chat rooms.Basically the staff talks to only 1 person at a time.
So basically the following should be the maximum load handled by the server every second ->
16 requests every second from each user(1 request every half second) to update the chat each of which goes through all the chat messages sent till now.
At max around 30-50 users will be visiting the portal at any given time , so they may send refresh requests say around 1 per every 4-5 seconds.But here the database query is very small as it has to go through only 4 rows of database ie the chatrooms.
So that gives around 30 requests to the server per second in which 16 are heavy requests which need to go through all chat messages sent by each user till now and 14 light requests which need to query only 4 rows of a database.
This will be deployed in the future on a server (RAM-256 GB upgradable to 1.5 TB , hard disk - 3*1.8 TB) and currently on a server (harddisk - 1900 GB and RAM - (around 128 GB)
I have the following 3 questions:
Will my current implementation work properly on the giver server constraints, if not I request
firstly improvements in the current system itself ( like reducing time between requests to update chat or database improvements )
Some better and easily implementable method as I don't have much time to change the complete thing
I am implementing an archive chat feature from the staff side so that , only non archived messages will be browsed through in those heavy requests every second, which will reduce the number of messages to be browsed considerably
If possible I would like to implement the database in such a way where there are separate tables for each staff and user combo. I don't know how to do this so if there is a way please point me in the right direction.
So that I just have to fetch the messages between a staff and user and just display them , and not go through all messages everytime, that should significantly reduce the load I presume.
I have closely followed the chat implementation on the following link
https://github.com/MiniGunnR/django-jquery-chat-application
https://www.youtube.com/watch?v=Z8Gjm858CWg&t=322s
I was wondering about the performance of WSO2 throttling. Whilst checking it out, I did the following :
I created a new subscription tier (say Tier1)
I set a limit of 10 requests per hour on it
I created another subscription tier (say Tier2)
I set a limit of 20 requests per hour on it
I allowed my API to use those tiers and created a test application to use the API with Tier1
Using the API console, I started sending requests to my API
After the 10 calls(though it exceeded 10), I unsubscribed the test application and subscribed to the same API using the same application using Tier2
It took around 15 mins for the throttler to unlock. Which brings me to my first concern ...
How long does it take for a change in tier subscription to reflect on the same application????
In relation to the excess calls going through, I also set up tiers with limits on a per minute basis. Once again, I noticed excess calls going through.
What I also noticed was that this excess was in the initial number of calls and the throttling worked normally after those initial excess calls.
Which leads to my next ...
How long does it take for a newly set up tier to throttle properly? In the per-minute basis, I assume that some calls carry over to the next minute. Am I right in assuming that?
Any help in understanding this would be much appreciated. Thanks
We want to collect some metrics about our client public Facebook pages (~1-5K users) on a daily (or weekly) basis.
I'm talking about 3-5 typical metrics : "likes", "fan posts" etc.
I understand that according to the "Rate Limiting on the Graph API" documentation [1] it's possible to have 200 calls per 1 hour.
For now we don't have any FB public application that can help us to increase this limit. To generate application token we will create it to but I doubt it will have a lot of users.
Does anybody know will we have problems with rate limit exceptions while invoking Graph API more than 200 times per 60 min.?
I guess our expected rate is 5-10K calls per 60 min (once a day).
Phrase from the documentation [1] "Rate limiting in the FB Graph API is encountered only in rare circumstances" gives me hope that it won't be a problem.
Thank you!
[1] https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
You won't have any problems initially. Facebook does not necessarily block apps immediately for being over the limits.
As per their documentation
If your app is making enough calls to be considered for rate limiting by our system, we return an X-App-Usage HTTP header
So, if you don't get any X-App-Usage header,Then your app hasn't be considered "worthy" of throttling by their automated systems yet.
So it would be best to check for this header, while making your api requests. Once you start receiving this Header, it would be best change your frequency of the API calls or give a timeout.
I just want to know the user rate limit calculated in Facebook API is for user id basis or token basis.I have 2 access token for the same userid for the same app.Could i make 600calls/600sec/token? Can anyone help me?
Rate limit is calculated on both, per account basis (limit is undocumented) and per token basis (token from each user adds ability for the app to make additional 200 calls per hour).
Rate Limiting - Graph API
Account Level, on a per user basis. The total max number of calls from all tokens which belong to a user (to different apps) is not known. This type of rate limit throws Error Code 17.
These limits apply to calls made using user access tokens. Your app will receive error code 17 if this limit is reached. This happens when a specific user account is making too many calls to the API. Note:This can include user calls made over many apps and not just yours.
Application level, on per-token basis (only one token from one user per app), and it's documented (Error Code 4):
The total number of calls your app can make per hour is 200 times the number of users. This isn't a per-user limit; any individual user can make more than 200 calls per hour, as long as the total for all users does not exceed the app maximum. For example, if your app has 100 users, the app can make 20,000 calls per hour.
So,
token can add 200 additional calls to your app (if App hits limit, all API calls with all tokens generated for this app get error code 4),
and
the user is allowed to make some (undocumented) amount of API calls per all apps (if the user hits limit, all API calls with all tokens generated for this user get error code 17)
200 API calls / user / hour
So each access token for unique user has it's own 200 calls per hour. If you use app token, you have just total of 200 requests per hour.
Source:
https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Edit:
Only applies to Graph API. For Marketing API, see the Marketing API rate limiting
Also note that a single HTTP request can count as multiple API requests. For example the following request counts as 3 API requests:
https://graph.facebook.com/photos?id=4,5,6