I've searched Google and the Twitter documentation for a very straightforward answer for how the following scenario would play out. Specifically, I'm wanting to understand how Twitter's rate limiting works on a "per user" and "per app" basis. Can someone take a look at the example below and explain to me what would happen. And please don't just refer me to a Twitter documentation URL! Thanks in advance.
Example:
The "GET friends/list" API call is currently limited to 15/user and 30/app within the 15 minute window (See https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list).
If I have 4 users who all make the "GET friends/list" API call 10 times each within a 15 minute window (i.e. 40 calls made) does that mean I violate the 30/app limit? I'd still be within my limits for each of my 4 users, but do their individual calls eat away at the app limit too? Or is the app limit entirely separate and related solely to my app's token/secret?
The number of users (aka user tokens for your app that you've saved in your app store/config) give you that many times the specified per user limit (different for different APIs) for your app.
In your example, you're well within your limit if you make 10 calls per 15 minutes per user to the 'GET friends/list' API call since you have 60 (4 X 15) calls you can make per 15 minutes.
App limit applies if you don't have user tokens via user authZ/consent and are calling in application context only.
You should try your scenario with a 15 minute sleep after iterating over the 4 users and making 10 (upto 15) calls each in the user context (on the user's behalf) and you'll see that all works fine.
Related
I'm in the process of devolving a new tool for a company app. The tool will be sending homogeneous number of searches to amadeus API. Is every search result is considered as a request? A sample search of a user will have to search the api 1000 times are these searches considered as requests? Because if the company has 10000 request limit per month it's going to be over by 10 users! I need to understand this please.
Every time you call an API (every time you use GET/POST verb) you do a "request".
The limitation (quota) is only in the test environment, you don't pay for it but you have a limited number of calls and you only have access to a subset of data.
In production, you don't have any limitation on the total number of queries you can do. You get access to our full set of data (live) but you pay per use (you pay for each request you do).
You have a limitation on the number you can do per second (TPS: 10 in production / 5 in test).
If I have a Database of 50,000 users with there address and every time a new user is created the want to see who are the top 10 closes users by driving distance.
Google starts charging 50 cents for 1000 requests. I'm looking a better may to do this that would limit my costs.
Also is there a better way then having to run the API against all 50,000 users every time a new user is added?
At first you may select closest users by the direct distance. You don't need paid functionality for that.
Let's say 20 would be enough bacause it's very unlikely that so many addresses will be the closest by distance but farther by driving route than others.
In that case you need only 20 requests to check the users closest by route.
I have routines that synchronize Class/Roster information between an SIS and Google Classroom. Everything has been running smoothly until very recently (11/1/2016). Now we're seeing the following message in all of our log files for routines that handle Classroom syncs.
Insufficient tokens for quota group and limit 'DefaultGroupUSER-100s' of service 'classroom.googleapis.com', using the limit by ID...
We perform batch requests whenever possible and these errors are showing up in individual batch "part" responses. The fact that these errors suddenly started showing up for ALL of our Classroom routines makes me think that something changed on the Google end of things.
I've been playing around with the throttling on our end by changing both the number of requests that we send in each batch (docs say that you can send 1000 per batch) as well as the total number of requests/batches that we're sending per 100 seconds (docs say you can send 50/s/client and also 5/s/user). Interestingly, the quotas indicated in the development console display slightly different but I assume they are to be interpreted in conjunction with one another.
I've throttled things down to the point where we're not even getting close to 5 requests per second and I'm still getting these errors back from the server.
Can someone provide some suggestions or solutions. Has anyone experienced this lately?
Let me know if I any additional information is needed.
I've been asked to carry out some testing to assess the response time under varying load on an API that is being developed in my current job. I’ve got a very basic knowledge of jMeter so I’m looking at this as my chosen tool to use.
Here’s quick Back ground info of what I’m tying to achieve:
I want to test the API by simulating a number of unique Json calls each made by different users. Each unique Json call contains a unique user ID and item number.
Lets say for example I want to test, 10 different users, all making calls for different Items to the API at once.
I’m a little confused with the terminology and difference between thread groups and users and loop count (which are found inside thread groups) and how best to use them. I couldn't find an answer on the jMeter site or on here so have come up with what I think may be a possible approach....
From my understanding of how jMeter works. In order for me to achieve my aim would require me to create 10 separate thread groups within the test plan, each of these having their unique Json body data configured.
For example : Thread group 1 containing request 1, Thread group 2 containing request 2, Thread group 3 containing request 3, Thread group 4 containing request 4, Thread group 5 containing request 5.... and so on.
( note, I would uncheck the option ‘run thread groups consecutively so that all requests get sent at once)
If the number of users and the loop count in each thread group is set to 1 then each call is made only once. Meaning a total of unique 10 calls would be made during a single test run?
I guess, what I’m kind of asking is in my scenario, does the term thread group actually represent unique users, and if so what does the number of threads(users) actually represent
I think I've got this right but it would be good if someone more experienced might be able to add some confirmation or advice to point me in the right direction if I've got this wrong.
Thread Group is an element in JMeter test plan which is responsible for executing the scenario/business work flow for the given set of users & for the given duration(or iteration/loop count).
Lets say I have a business flow like this.
users login
search for product
select a product
order the product
Another business flow for the same application would be
Admin users login
Search for users
modify the order/cancel the order/issue refund
I would create 2 thread groups for 2 different work flows.
In production/live environment, I might have 1000 users searching for products and 500 users might be placing the order.
I might have only 10 admin users to provide support for 1000 users - to provide refund/modify the order etc. [some might do refund / some cancel / some modify]
So,
Thread Group 1 [users1=1000, rampup=3600,loop count=forever, duration=7200(2 hrs)]
users login
search for product
If Controller [let only 500 users to order product]
select a product
order product
Thread Group 2 [users1=10, rampup=600,loop count=forever, duration=7200(2 hrs)]
Admin users login
Search for users
Throughput controller [40%]
modify the order
Throughput controller [30%]
cancel the order
Throughput controller [30%]
some other support
As you mention you are new to JMeter, I would suggest you to check this.
JMeter Tips/Tricks for beginners / Best Practices
JMeter - REST API Testing
I believe using Synchronizing Timer to ensure all 10 threads are running at exactly the same moment will be easier and smarter choice.
And this is some general information regarding how JMeter works:
JMeter starts the specified amount of threads during ramp-up period
Each thread starts executing samplers upside-down (or according to the Logic Controllers)
When there are no samplers to execute and loops to iterate - thread is being shut down. Elsewise it starts over until desired test duration or loops count is met/exceeded.
Hopefully it clarifies everything
I wrote a little Script using Python and Tweepy to save the tweets for a list of users and also to get some basic properties for those accounts.
Somehow the number of tweets stated in the user profile under statuses_count
(for an example of the json description of an account:
https://api.twitter.com/1/users/show.json?screen_name=TwitterAPI&include_entities=true )
does not match the number of tweets i get when iterating through the tweets of the same users profile.
I am aware of the fact, that twitter limits the number of tweets per user available through the API to 3200 and even does not guarantee this number, but this behavior does even occur with users who have well less than 3200 tweets
My question is, whether this difference is common and why this happens?
Is this just an issue of the twitter API, is it caused by deleted tweets (maybe they still count for statuses_count but can not be fetched anymore?), ...?
Thanks!
Thomas
I haven't messed with the Twitter API in several months, but I remember back when I was working with it I found inconsistencies due to retweets not showing up when iterating tweets, but getting counted in the number of Tweets. This seems to corroborate that, but its several months old and things may have changed since then.
Make sure include_rts is set to true, t, or 1 (in addition to specifying the same for include_entities, which you have done). When these aren't included by default (e.g. user lists) then you can get fewer tweets than what you specified with count.
The Twitter API documentation isn't clear on what the defaults are so it's safer to explicitly specify these optional parameters. And since you're specifically working with the user timeline you might also want exclude_replies turned off.