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.
Related
I have 5 thread groups each one have 3 api requests and each thread should execute one after one, in 1 hour load test should achieve 120 hits per second.
Pacing: 5 sec
Thinktime: 8 sec
Each thread single iteration time: 20 sec
So for this how much users I need to give to achieve required 120 hits per second and how can I do load test for 5 thread groups because each one should execute one after one.
It's a matter of simple arithmetic calculations and I believe question should go to https://math.stackexchange.com/ (or alternatively you can catch a student of the nearest school ask ask him)
Each thread single iteration time: 20 sec
means that each user executes 3 requests per 20 seconds, to wit 1 request per 6.6 seconds.
So you need 6.6 users to get 1 request per second or 792 users to reach 120 requests per second.
Also "pacing" concept is for the the "dumb" tools which don't support setting the desired throughput and JMeter provides:
Constant Throughput Timer
Precise Throughput Timer
Throughput Shaping Timer
any of them provides possibility to define the number of requests per second, especially the latter one which can be connected with Concurrency Thread Group
I ran a jmeter test case where I found :-
Samples - 26133
99% Line to be - 2061ms
ThroughPut - 43.6/s
My question is how can the throughput be 43.6 requests per second when then 99% Line is showing at 2061ms. From my understanding that means 99% of the samples took NO MORE THAN this time. The 1% remaining samples took at least as long as this.
So Shouldn't the throughput be less than 1 request per second? How is it able to serve 46 requests per second when 99% itself take 2 seconds to respond?
99% is response time
Throughput is the number of requests for the test duration
Given the number of samplers and the throughput my expectation is that you ran your test for 10 minutes.
If you would execute your test with 1 user having response time of 2 seconds for 10 minutes you would get 300 samples. Looking at the numbers I can assume that you had something like 87 users.
And this 87 users (or whatever is your number) is a key point because throughput indicates concurrency
1 user which executes 1 request each 2 seconds - throughput will be 0.5 hits per second
2 users which execute 1 request each 2 seconds - throughput will be 1 hit per second
4 users which execute 1 request each 2 seconds - throughput will be 2 hits per second
etc.
More information:
JMeter Glossary
What is the Relationship Between Users and Hits Per Second?
I am running a Kusto Query in my Azure Diagnostics where I am querying logs of last 1 week and the query times out after 10 mins. Is there a way I can increase the timeout limits? if yes can someone please guide me the steps. I downloaded Kusto explorer but couldnt see any easy way of connecting my Azure cluster. Need help as how can i increase this timeout duration from inside Azure portal for query I am running?
It seems like 10 minutes are the max value for timeout.
https://learn.microsoft.com/en-us/azure/azure-monitor/service-limits
Query API
Category
Limit
Comments
Maximum records returned in a single query
500,000
Maximum size of data returned
~104 MB (~100 MiB)
The API returns up to 64 MB of compressed data, which translates to up to 100 MB of raw data.
Maximum query running time
10 minutes
See Timeouts for details.
Maximum request rate
200 requests per 30 seconds per Azure AD user or client IP address
See Log queries and language.
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/api/timeouts
Timeouts
Query execution times can vary widely based on:
The complexity of the query
The amount of data being analyzed
The load on the system at the time of the query
The load on the workspace at the time of the query
You may want to customize the timeout for the query.
The default timeout is 3 minutes, and the maximum timeout is 10 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.
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).