This is regarding rate limit issue in shield waf.
If rate limit is 10r/s and we send 10 request in a second on what order the requestes will be counted in
What will the sequence of requests landing in
Ideally all requests should be passing what could be the reason if an intermittent request is failing due to rate limit
If 12requests are passed ideally last two should be failed ...but if the 6th request is failing and last 2 are passing what could be the reason ...
Related
I am trying to call Amadeus API in parallel (/v1/shopping/hotel-offers) in the test environment. Unfortunately when I start 3 threads simultaneously, then only the very first one gets the OK response and the others get HTTP 429 Too Many Requests responses.
I have not exceeded the monthly limit quota yet, so that error is really related to the parallel execution.
Does anybody know what are the exact limits (#requests/sec or #requests in parallel) ? Is it even possible to have more than one request at a time ?
The throttling is not the same depending of the environment:
Test: 10 transactions per sec per user (10 TPS/user) -> With the constrains: not more than 1 request every 100ms.
Production: 20 transactions per sec per user (20 TPS/user) -> With the constraint: not more than 1 request every 50ms.
has anyone had this issue? ive been using uber api for months to order rides, but last week something changed, and evey time i try ordering uber pool, the v1.2/requests/estimate endpoint gives me an estimate and fare_id, and when i book the ride, i get http 200 success. but then a few minutes later i get error no_drivers_available. this does not seem to happen using uberX. i've tried ordering rides in places that defintely have drivers (i.e manhattan) but i always get the same error after a few minutes
I am trying to understand latency vs maximum number or requests that can be served per second.
What I understood RTT is time taken for message to reach destination and acknowledgement back to source. So I assume server can only serve maximum requests per second should not exceed more then sum of avg round trip in a give second. My local ping test shows as
> ping 127.0.0.1
rtt min/avg/max/mdev = 0.089/0.098/0.120/0.012 ms
on average it takes 0.098 ms just for network round trip, which means 10 ping req/ms. So I assume that in sequential order a client can only execute maximum of 10_000 req/sec. while it turns out I am wrong. redis-benchmark tool shows something different.
> redis-benchmark -t set -c 1 -h 127.0.0.1
====== SET ======
100000 requests completed in 2.53 seconds
1 parallel clients
3 bytes payload
keep alive: 1
100.00% <= 1 milliseconds
39588.28 requests per second
a single client is able to execute 39 req/ms while i am expecting maximum of 10req/ms.
Can anyone help me where I went wrong or misunderstood ?
Commands can be pipelined even when using a single logical client thread, meaning: you can send lots of requests before the first response comes back. Responses always come back in request order (unless you're using pub/sub), so a pipelining client simply needs to keep a queue of sent messages that have not yet seen responses, and pair responses to requests as they arrive.
So: you aren't strictly bound by latency, although that remains a useful number. The raw throughout number (bound by bandwidth and server capacity) is also meaningful, since it is often the case that you want to issue multiple commands.
what is BestBuy API call limit for the product details? How many calls per hour/day ?
The default call limits for approved accounts is 5 queries per second/50,000 queries per day. If you surpass these limits, you will receive a 429 error code with an error response stating quota limit exceeded.
Just for anyone who runs across this question the error code has changed to 403. Source: https://bestbuyapis.github.io/api-documentation/#errors
The default call limits for approved accounts is 5 queries per second or 50,000 queries per day. If you go pass this limits, you will receive an error code with an error response saying that you have exceeded the quota limit. The error code number is 429.
In the documentation we can find that The limits are based on a moving window that tracks the number of requests you send per hour. (https://developer.foursquare.com/overview/ratelimits) but in the practice my rate limit isn't recharged even if I wait several minutes.
What happened? Did they change the implementation of API rate limits?
The window should still update be updating in real time.
To be clear, if your rate limit is 500, at 11:00, you send 5 requests, the X-RateLimit-Remaining will be 495. If you wait a few minutes to 11:05, and send another request, X-Rate-Limit remaining will be 494 -- it won't have reset yet.
It's not until 12:01 that you'll get back the 5 requests that you'd made at 11:00. So, if you request again at 12:01, your limit would be 498 (-1 for the request you just did, -1 for the 11:05 request). Requesting again at 12:06, and you'll be back up to 499 (the full limit, minus what you just used).