I don't understand something about mws throtlling.
For example with this api:
http://docs.developer.amazonservices.com/en_US/products/Products_GetMatchingProductForId.html
The Max request quota is 20. So I understand that I can submit 20 different ids on each request. But in the table there written that 'Maximum: Five Id values'.
So what the 20 represents?
20 represents the maximum about of requests you can make at a time. Each request can have a maximum of 5 Id values in the IdList. So, essentially you can submit requests for 100 (20 * 5) product Id's at a time. Then you have to wait until the quota is restored, which is 5 per second. You are also capped by an hourly request quota, in this case 18,000 requests per hour.
Do some math to figure out how many requests you need to make and space those out so enough time is given for the restore to kick in.
There are typically 2 or 3 components to Amazon throttling.
They use a modified leaky bucket algorithm. The Quota is how many separate requests you can submit at a given instant, assuming you have not already consumed any requests. This is how much the bucket can hold.
For every request you submit, the bucket 'leaks' one unit.
The restore rate, is how quickly the bucket refills.
For the API call you linked, how many requests can hypothetically be sent in 1 second? If my math is right (give or take 1) you should be capable of making 25 requests in that first second, because you exhaust the bucket, but in the first second, it also refills 5 requests.
Keep in mind that Amazon caps you on many API calls with an Hourly / Daily cap.
Edit
Keep in mind the throttling caps how many Requests you can make, not how many ID's, reports etc etc can be submitted inside of each request.
Related
how can we keep fixed number of active concurrent users/requests at time for a scenario.
I have an unique testing problem where I am required to do the performance testing of services with fixed number of request at a given moment for a given time periods like 10 minutes or 30 minutes or 1 hour.
I am not looking for per second thing, what I am looking for is that we start with N number of requests and as any of request out of N requests completes we add one more so that at any given moment we have N concurrent requests only.
Things which I tried are rampUsers(100) over 10 seconds but what I see is sometimes there are more than 50 users at a given instance.
constantUsersPerSec(20) during (1 minute) also took the number of requests t0 50+ for sometime.
atOnceUsers(20) seems related but I don't see any way to keep it running for given number of seconds and adding more requests as previous ones completes.
Thankyou community in advance, expecting some direction from your side.
There is a throttling mechanism (https://gatling.io/docs/3.0/general/simulation_setup/#throttling) which allow you to set max number of requests, but you must remember that users are injected to simulation independently of that and you must inject enough users to produce that max number of request, without that you will end up with lower req/s. Also users that will be injected but won't be able to send request because of throttling will wait in queue for they turn. It may result in huge load just after throttle ends or may extend your simulation, so it is always better to have throttle time longer than injection time and add maxDuration() option to simulation setup.
You should also have in mind that throttled simulation is far from natural way how users behave. They never wait for other user to finish before opening page or making any action, so in real life you will always end up with variable number of requests per second.
Use the Closed Work Load Model injection supported by Gatling 3.0. In your case, to simulate and maintain 20 active users/requests for a minute, you can use an injection like,
Script.<Controller>.<Scenario>.inject(constantConcurrentUsers(20) during (60 seconds))
Under Compute > Memcache we have some statistics:
HitRatio, Items In Cache, Oldest Item Age, Total Cache Size etc.
Then we can also see stats for 20 commonly used keys ordered by either Operation Count or Memcache compute units
my question is, is it possible to figure out how many times per second a key has been read (or read + written) from memcache using just memcache stats?
For example, if i have 1 million hits and the oldest item is 1 day old, and my memecache key uses 5% of the traffic,
Could I go (1 million hits * 5% = 50,000 hits) / 24 hours = 0.57 hits per second.
Really I have no idea what the statistics on the memcache viewer actually mean - For example the statistics don't even reset if memcache is flushed.
Cheers.
I am pretty sure counting this way won't return what you want. As explained in the python memcache statistic paragraph, the age of your items reset when they are read. So the oldest item being 1 day old just means it has been in memcache for a day since it was read.
To figure out how many times a second a key has been read, you might want to use a sharding counter, or some other form of logging, then retrieving the logged data with the Logs API to interpret them. It can't really be done directly from the memcache statistics (might be an interesting feature to request on Google's Public Issue tracker though)
Suppose my parse.com api call limit is 30 api calls per second (the free tier). Suppose also that when opening an app I've created, I issue five api calls (1 call to the cloud code, three queries, and one save object).
Suppose 60 users happen to open the app at the same time. Would Parse begin rejecting some API calls?
The typical use case for my app would be 1 or maybe 2 api calls per second with 1000 active users. However, it is possible in some rare situations that I may issue 45 api calls per second. Is there a way around this without having to pay for a large number of API calls per second? It feels like I'm paying for cable TV (24 hours of 200 channels while I only see 2-3 channels 1 hour a day).
One of the Parse guys mentioned recently that they count calls per minute. So the limit is actually 30*60/min or 1,800/min.
This allows for short bursts of activity to not cause problems.
After the 1,800th call in a minute, all further calls will be rejected.
I have about 15 fruits, that has to hit a url:
http://myurl/fruit1
http://myurl/fruit2
http://myurl/fruit3
...
http://myurl/fruit15
It can occur asynchronously, what is the best way to get all 15 without tanking the server? Each item should be added to a list as they are retrieved.
Note that this happens every time a user visits the page. The fruit data does not change. Its going out to fetch the data, and add to list. My concern is the fact that it has to make multiple requests, which I want to not affect the performance of the application/browser (i.e. freezing for moments while its waiting for an HTTp request to return as information for each fruit is about 1.5MB.
How frequently does the fruit data change?
If frequency of data change is low, then caching should solve a lot of problems outside of the initial retrieval of the data. If the frequency is high consider requesting a range or list of fruit from the server instead of individually. This will reduce a large amount of transfer overhead (1 request vs 15 requests).
I have an application where you can select entries in a table to be updated. You can select 50 and hit 'send it' and it will send all 50 as 50 individual ajax calls, each of which calls controller X that updates the database table Y. The user said they selected 25 but I see 12 in the logs and no trace of the other 13. I was wondering if maybe I hit some limit with the number of requests or the length of the queue. Any Ideas?
(Running this locally it had no problem with 50-100 being sent at once it just took like 2 seconds for all of them to finally callback).
This question cannot really be answered as there's no "hard limit" that would cause your ajax calls to be lost. However, overloading the server (if you only have one) can cause requests to be queued up and/or take a long time which in turn may cause requests to timeout (depending on your settings). Chances are if you are making 50 ajax calls instead of just one then there is some room for optimization there and I'm not sure that classifies as premature.
In the end, I think the most and best advice you will get is to profile and load test your code and hardware to be sure otherwise we're all just guessing.