Is it possible to configure JMeter to log latency in microseconds or 10 or 100 microseconds (anything more granular than millisecond)?
Related
I am trying to send 1100 requests per minute to my API endpoint for a period of 5 minutes, so in total, I will make 5500 requests to the endpoint.
Based on the above requirement, Here is how I have set up my Jmeter:
It seems like I have misconfigured Jmeter, because in the end I can see Jmeter has made 8401 requests to the API instead of 5500.
What have I missed in the configuration?
Does the "Infinite" check-box need to be checked or unchecked?
The number of requests you're expecting (which is 5500) for this test plan is wrong.
As per your expectation, I think, you are making confusion between the Threads and Requests.
Ramp up is the time in which all the users arrive on your tested application server.
Requests are simulated by samplers but threads are the simulation of users.
According to your test plan:
- Total Number of Threads: 1100 vitual users
- Ramp-up time: 60 (1 min)
- Loop count: Infinite
- Test duration: 300 sec (5 min)
- No of requests/sampler in Test Plan: Unknown, assuming it 1
JMeter Execution:
JMeter will kick off those 1100 virtual users in 60 seconds according to the ramp-up time. So, (1100/60)~ 18 users will be active in every second for the first minute of your test. Each thread/user will execute the requests or samplers you have defined in your test plan hierarchy. As you have defined the loop count to infinite, each thread will execute the requests repeatedly until the test finishes. After 60 seconds, all of your 1100 users will be actively hitting those samplers/requests for the remaining 4 mins.
So the total number of requests you will be able to make through JMeter depends on your application response time.
If the avg response time of your requests is 1 second (assuming you have only 1 requests in your test plan), then you will be able to hit total 264000 (264000/240 = 1100 requests per second) for the last 4 mins (when all of your 1100 users are active) of your tests. You can also verify this accordingly by using Active Threads Over Time and Hits Per Second listeners.
So, Please double check the avg response time of your application or the requests/samplers you are using in your test plan.
If you want to control JMeter's throughput to 1100 per minute, you can use a Constant Throughput Timer at your test plan level and use target throughput value as 1100.
Do not forget to add the count of ramp-down time in your test duration. Yes, when you ramp up i.e. in the first minute generally you get more requests as threads are starting. In your case, your test duration should be 7 mins (60 seconds for the ramp-up 1100 users + 300 seconds for 5500 requests + 60 seconds for the ramp down for 1100 users).
You can also check this thread for more : How should I calculate Ramp-up time in Jmeter.
Please note- The total number of requests is related to throughput, Whereas the number of active threads performing the same activity is related to concurrency.
I am trying to send 1100 requests per minutes to my API endpoint for a period of 5 minutes, so in total I will make 5500 requests to the endpoint.
I don't know how you came with this 5500 number but this is not very correct.
Your setup means that:
JMeter will add 18 virtual users each second for 60 seconds
After 60 seconds pass JMeter will run 1100 users for another 4 minutes
The total number of requests JMeter will be able to make will mostly depend on application response time.
If you want to limit JMeter's throughput to 1100 requests per minute consider using Constant Throughput Timer or Precise Throughput Timer
If you don't want to limit JMeter's throughput but want 5500 executions either:
Set "Loop Count" to 5 (but in that case you might fail to get 1100 concurrent users)
Or use Throughput Controller in Total Executions mode so JMeter would stop after executing 5500 requests
I am using Jmeter 4.0 with Throughput Shaping Timer and I have mentioned my configuration as follows:
bzm - Concurrency Thread Group:
Target Concurrency 1000
ramp up time : 1
ramp up steps: 1
Hold Target Rate: 100 min
jp#gc - Throughput Shaping Timer
Start RPS: 333 || End Rps: 333 || Duration(sec): 1200
Since the test duration is mentioned as 1200 seconds and Rps is 333/sec so number of request hits through the test should be (333*1200) = 399600. But actual number of hits coming in range of 400000 - 410000 Requests per second.
How can Throughput Shaping Timer be restricted to not send extra requests?
Your Total test duration isn't 1200 seconds. Looking into your Concurrency Thread Group Configurations, your test duration is exactly 6001 seconds (Ramp up for 1000 user is 1 sec and the Hold Target Rate time is 6000 seconds).
To get your desired RPS, You have to follow the below formula to define the number of threads in Concurrency Thread Groups:
Threads pool size can be calculated like RPS * <max response time> / 1000
If your response time is 1 second, then 333 Threads are enough to achieve this RPS. You have used more threads in this case I guess.
According to your given test plan, it is working like 1000 users are active in 1 second and then they will try to achieve 333 RPS for 1200 seconds and then they will maintain 1000 users requests for remaining time (6001-1220=4801 seconds) as you mentioned 1000 users will hold the load for 100 mins. For this reason, you are getting extra requests than desired.
So, Define number of threads and ramp up time accordingly in your Thread groups and also sync your test duration properly (in this case hold load time could be 20 mins not 100 mins).
JMeter is not capable of immediately stopping 1000 threads when the Throughput Shaping Timer reaches its duration limit, JMeter "tells" threads to stop one 1200 seconds pass and it might take a while to gracefully shut the threads down.
Given your setup the only way of having exactly 399600 samplers is using Throughput Controller in Total Executions mode like:
This way you will get confidence that not more than 339600 samplers will be executed (the number can be less by the way if your application response time will be higher than 300 ms)
I had got stats from log which stated that on avg we have peak load of 3000 logons in 1 hour.
How do I work out the rampup period for jmeter to replicate the same behaviour in 1 hour or 30 mins or 2hr duration
It is not about the ramp-up period, it is more about limiting the rate of requests which are being sent by JMeter to certain rate. So you should be looking at Constant Throughput Timer in order to limit JMeter's throughput to the desired rate.
For example,
If you want 3000 logins per hour it stands for 50 logins per minute add Constant Throughput Timer as a child of the "Login" request and configure it as follows:
Target Throughput: 50.0
Calculate Throughput based on: all active threads
Similarly if you want 3000 logins in 30 minutes - Throughput should be 2x times higher: 100.0 samples per minute
And finally if you want 3000 logins in 2 hours - the Throughput should be 2x times lower: 25.0 samples per minute
You might also be interested in Throughput Shaping Timer, it acts similar to the Constant Throughput Timer but it is more precise when it comes to periods lesser than 1 minute and you can also create "Load Profiles" with it. You can install Throughput Shaping Timer using JMeter Plugins Manager.
I have set the number of threads and ramp-up time to 1/1 and I am iterating my 1000 records from data.csv for 1800 seconds.
Now given the numbers, I have set the CTT, constant time throughput to 2000 every minute and I expected the average throughput to be 2000/60 = 33.3/sec, but I get 18.7/sec, when I increased the throughput to 4000/60, I still get 18 or 19/sec.
Constant Throughput Timer cannot force threads to execute faster, it can only pause threads to limit JMeter's throughput to the defined value.
Each JMeter thread executes samplers as fast as it can, however next iteration won't start until previous is finished so given you use 1 thread - the throughput won't be higher than application response time.
Also be aware that Constant Throughput Timer is accurate enough on minute level so you can rather manipulate "requests per minute" rather than "requests per second", if your test is shorter than 1 minute - consider using Throughput Shaping Timer
So I would recommend increasing the number of virtual users to i.e. 50.
See How to use JMeter's Constant Throughput Timer for more details.
I guess your application average response time is around 50ms. Which means a single thread can only perform about 20 hits/sec (1 sec / 0.05 sec per hit = 20 hits/sec).
You have 2 solutions:
increase the number of threads to parallelize requests sent,
or make you app response faster (obviously harder).
At some point, when you application can't handle more load, you should see the hits/sec dropping and the average response time increase.
The graph below shows you an example of application which has a steady response time with up to 20 concurrent threads.
Please help me to achieve this type of load testing in Jmeter,i have configured Scheduler configuration but it is not running as per Duration as 60 minutes with in 10 seconds it is completing the requests and my Vusers -5 and Loop Count-50
Please help how to prepare this type of scenarios.
If you need 200 requests - decrease loops count to 40 (5 users x 40 loops == 200 total requests)
Also consider using Constant Throughput Timer or Throughput Shaping Timer to limit the throughput to 200 requests per minute (something like 3.3 requests per second).