I am trying to load test an API and I am trying to make sure I fire only 2 requests in a second due to the throttling limit set at the API Gateway level so if the third request is sent within a second (this happens if the response time of the earlier request is < 1 sec) then I get HTTP-429 error saying 'too many requests'. Please could someone suggest if I can use any timer to achieve this?
Thanks,
N
Constant Throughput Timer is the easiest of built-in test elements, 2 requests per second is 120 requests per minute. However it is precise enough only on "minute" level so you might need to play with ramp-up period
Precise Throughput Timer is more "precise" but a little bit harder to use as you need to provide controlled throughput and test duration
If you don't mind using JMeter Plugins there is Throughput Shaping Timer which provides the maximum flexibility and visual way of defining the load
For this particular case, I suggest the Arrivals Tread Group. This TG will let you exactly configure the desired TPS (Arrival Rate), plus the plugin will instantiate the necessary threads to generate the load. No need to guess how many threads/vusers you'll need.
Related
My test has 1 Authentication API and 2 other API's. I need to run Authentication API once and other 2 API's to generate X request per minute.The Auth API should run first then followed by other 2 API's. How can I create this scenario in thread group.
Put your "Authentication API" (whatever it is) under the Once Only Controller
Constant Throughput Timer is a good option but be aware of several constraints, i.e.
it is precise enough on "minute" level, the throughput will be applied more or less after 1st minute of your test, prior to that you need to manipulate the ramp-up period
it can only pause the JMeter Samplers execution rate to limit it to the defined number of requests per second, it won't kick off any extra threads in case if current amount is not enough to conduct the required load
If you want to get the number of requests per second you set in the "Target throughput" make sure that "Calculate Throughput based on" is set to all active threads
In the majority of cases it's easier to use Throughput Shaping Timer or Precise Throughput Timer
Which controller or timer I should use for controlling rps ?
Can you please let me know?
Thanks,
You can achieve 10000 RPS with 10000 threads (virtual users) only if your application response time is 1 second
if your application response time is less than one second - you will get more RPS
if your application response time is more than one second - you will get less RPS
There are 2 main per-requisities:
Your application has to be able to respond fast enough because if it is not capable of supporting 10k requests per second - no matter what you do you won't be able to reach the target throughput as JMeter waits for the response prior to starting the next request
JMeter has to be able to send requests fast enough so make sure to follow JMeter Best Practices and it might be the case you will have to go for distributed testing mode
The easiest way of conducting X requests per second load is using Concurrency Thread Group and Throughput Shaping Timer combination, both can be installed using JMeter Plugins Manager
I am trying to configure a test for signup-login with invalid credentials imitating bruttforce attack. However, I want to make requests as a single user.
So the scenario is the next:
Request to sign up with valid params;
Attempt to log in with invalid params in a loop.
I am adding throughput timer but then I need to set up a high number of threads to generate for example 1 request per second.
How can I set exactly one user and run only one request per second in a loop?
UPDATE - SOLUTION
Everything was rather simple but still strange for me.
Maybe someone will face the same problem.
To get a number of requests per one user throughput timer should be placed not inside the controller but inside the thread itself.
To achieve Target Request Per Second use Throughout Shaping Timer : How to use Throughput Shaping Timer
JMeter Plugin link : Download from here
Few Important Notes:
JMeter threads of Thread Groups in scope of the Element will be
stopped when RPS schedule finishes.
Provide enough working threads for your RPS, JMeter timers can only delay threads (and limit RPS). You may pair this plugin with Concurrency Thread Group using Schedule Feedback Function to dynamically maintain thread count required to achieve target RPS.
If you're using versions of JMeter lower than 3.3 and if you have RPS that lower at the end of test, make threads to lower also. Оtherwise you'll have a spike in last second.
Avoid using zero RPS value as start of test, this produce spike also
Avoid zero RPS during the test, this may lead to nasty effects
Now, practical example showing 1 RPS for 1 User:
You might want to reconsider the location of the timer, it obeys JMeter Scoping Rules so it gets applied to all Samplers which are in your Thread Group.
If you want to apply it to only one - make it a child of the relevant sampler.
Also be aware that Constant Throughput Timer is precise enough on minute level so you might want to switch to the Precise Throughput Timer
I am quite new to jmeter and try to do a performance test of my application. I want to generate 100 request per second scenario however my server takes 3-4 secs to respond to every request. I am running my test for 1 mins which means number of requests fired should be 60k within the time span. However jmeter actually waits for the response before it sends next request. Which is not what I am looking for.
How can I make sure that jmeter sends a new requests every second with 100 req/sec without waiting for the response so that the number of requests fired per min is 60k.
I am trying to use constant throughput timer with 60k as request per min, however that is not helping. Here is my test screenshot.
EDIT
I have done like this
And Throughput shaping timer being as
So ideally I should get number of samples as 3000?, still not getting that.
Make sure you provide enough threads (virtual users) under Thread Group, "vanilla" JMeter won't kick off any extra threads if actual throughput is less than target one you specify in the Constant Throughput Timer.
Another solution would be using Concurrency Thread Group along with the Throughput Shaping Timer. They can be tied together via feedback loop so if you use these test elements JMeter will start more threads if the current amount won't be enough to reach the desired requests per second rate.
You can install both using JMeter Plugins Manager
My suggestion is to consider using the Arrivals Thread Group. This TG will allow you to configure the desire average throughput (ATP); the TG will instantiate the required threads needed to achieve the ATP goal.
I have a very simple web service and I'm trying to measure its latency metrics under different throughputs -
If the system under test can't handle the target throughput, I want Jmeter to keep the same throughput, even if a lot of requests fail.
I tried implementing this using a large number of threads and a constant throughput timer, but Jmeter tended to simply not reach the target throughput instead of requests failing.
Any recommendations?
Constant Throughput Timer has 2 main limitations:
It is accurate enough on minute level so you need to ensure that your test is running long enough (minute or more). Also its effect is not immediate so during 1st minute of your load test you need to control virtual users arrival rate using Ramp-Up Period setting on Thread Group level
Constant Throughput Timer is only capable of pausing the threads to limit their execution rate to the "target throughput", it will not be able to kick off any extra threads so make sure you define enough virtual users again on Thread Group level
Given Web service == HTTP transport and HTTP being stateful protocol (each JMeter thread (virtual user) will wail for response from the previous HTTP Request sampler prior to starting next one you can speed things up by defining a timeout for your HTTP Requests so they would fail earlier. The best place to put the timeouts is HTTP Request Defaults, this way you will be able to do it in a single shot for all HTTP Request samplers in scope
You may also want to try Throughput Shaping Timer which is a little bit enhanced version of the Constant Throughput Timer.