-I has a request for post data to server.
-I config Jmeter with info :
Number of Threads(users) : 16
Ramp-up : 1 and check forever
I run jmeter about 15 minutes(900s) and stop.After,i view report and see report display about 45000 samples .
=> I think only 14400 samples expect for 15 minutes but display more samples.
So,Can jmeter run more samples (> 16 thread in 1s) although i config 16 threads in 1s ?
Thanks,
JMeter tries to execute samplers as fast as it can, each thread sends request, waits for response, sends another request, etc.
You will get 14400 samplers only if response time for each sampler will be exactly equal to 1 second. If response time is less than one second - you will get more samplers executed within the given timeframe and vice versa.
If you need to throttle JMeter execution rate to 960 requests per minute (16 requests per second) you can use one of the following elements:
Constant Throughput Timer
Throughput Shaping Timer
Be aware that both timers are capable of only pausing JMeter threads to limit the load to the defined factor, they won't be able to kick off any extra threads to reach the target throughput in case if current is too low.
Related
I have the following scenario. So I have an OS process sample that will send a request to the console app and wait for the process to finish, I want to control the request to be line 6 Request in an hour.
So send 1 Request wait 10 min send another request wait 10 mins...at 20 min point after the first request send 2 requests (could have a wait time of 30 seconds) in between the request then at the 40 min mark have another request. I have been reading about precise throughput timers but I am not new to Jmeter so trying to get some help if possible.
1 request of 5k at : xx:00 min
2 requests ( 1 each of 2k, 5k ) at : xx:20 min ~
1 request of 2k at : xx:40 min -
1hr no activity
repeat steps 1-4 a few ( 3 ) times
There is no way to run requests with different throughput values within the bounds of a single Thread Group, the overall throughput would be the speed of the "slowest" request.
All JMeter timers like Constant Throughput Timer, Precise Throughput Timer and Throughput Shaping Timer are trying to spread the load evenly during the throughput period.
So your load pattern can be implemented only using Constant Timers or Flow Control Action samplers, whatever is more convenient to you.
Something like this:
You can use Test Fragments and Module Controllers to avoid copying and pasting the requests
if the number of samplers is very high, nearly 100, how to use throughput controller in jmeter?
i want all samplers to be sent with equal number by jmeter.
my test configuration:
ultimate thread group : 50 threads, 10 minutes, ramp up 10s, ramp down 10s
sampler1 ,
sampler2 ,
...
sampler100.
throughput controller is not used.
when the test is executed the total request numbers will be like this:
sampler1 : 150 ,
sampler2 : 145 ,
sampler50 : 5 ,
sampler100 : 0
this is not the case that i want.
if i use the throughput controller (all the samplers are in the throughput controller), the result will not change satisfactory.
have any idea for the solution?
Throughput Controller doesn't guarantee that its children will be executed specified amount of times (or at least once), it can only limit the number of its children execution to the defined value.
If you have 100 samplers and 10 minutes + 20 seconds test duration if average response time exceeds 6 seconds - not all samplers will be executed
If you want all the 100 samplers to be executed at least once within the bounds of 10 minutes time frame you need to limit the time JMeter waits for the response to something below 6 seconds, i.e. to 5 seconds.
In case of HTTP Request sampler the timeout setting can be found at "Advanced" tab
or better use HTTP Request Defaults, in this case you won't have to set the timeout 100 times.
Also make sure that "Action to be taken after a Sampler error" is set to Continue
as having 150 occurrences of execution of 1st sampler most probably means that there is an error somewhere and the user is restarted so it executes samplers from the beginning once again
I am having a requirement to perform a load testing for api's with 1000 request per minute. i have setup a stepping thread group as displayed below :
In above image you can see that i have configured the parameters as 20 threads per second ,so it will take 50 seconds to reach 1000 threads. but still graph shows 2 min and 31 sec to completed the 1000 request.so please help me to set it.
Please help me to configure it properly , my exact requirement is as displayed below :
1) 1000 threads
2) In 1 minute it needs to be completed.
Change stepping thread group settings to hold 60 seconds 1000 threads:
1000 threads (virtual users) will produce 1000 requests in one minute only under specific condition: response time must be 16.6 milliseconds.
If response time will be higher - JMeter will execute less requests
If response time will be lower - JMeter will execute more requests
If you want JMeter to conduct the load at rate of 1000 requests per minute it's better to consider Concurrency Thread Group and Throughput Shaping Timer combination
Throughput Shaping Timer configuration:
Concurrency Thread Group configuration:
I have created a set and just confused with the Loop Count and Ramp Up period.
I have a test set with the following parameters.
Threads = 30
Ramp Up Period = 30
Loop Count = 100
As per the page on
quora.
I suppose:
a) If Loop count is Zero, then each of the 30 threads will be starting every second. As per the shared the web page, I guess 30/30 * 100 ie 100 threads/requests will be hitting the server every second. Please correct me if I am wrong.
b) As per the above parameters, there will be a total of 30 * 100 threads/requests. Does this mean all the 3000 threads/requests will be sent within 30 seconds [ Ramp Up period ]
Assuming you have 30 users and 30 seconds ramp-up
JMeter will start each virtual user each second
Each virtual user will start executing samplers upside down (or according to the logic controllers, if any) as fast as it can (if you don't use timers) so the delivered load can be either more or less than 30 requests/second, it depends on how fast JMeter is executing requests and on your application response time as JMeter will wait for response from previous sampler before starting new one
When virtual user finishes executing all the samplers defined in test plan it will start over and do point 2 for 99 more iterations
When virtual user won't have more samplers to execute and loops to iterate it will shut down
A couple of tips:
You can use Server Hits Per Second listener to see how many requests per second you are actually making given your test plan configuration
You can control the number of requests per second via Constant Throughput Timer
Consider upgrading to JMeter 3.2 as newer JMeter versions normally contain new features, performance improvements and bug fixes
according to jmeter manual ramp up is:
How long JMeter should take to get all the threads started.
If there are 10 threads and a ramp-up time of 100 seconds, then each
thread will begin 10 seconds after the previous thread started, for a
total time of 100 seconds to get the test fully up to speed.
So if your goal is to reach 3000 request within 30 seconds the above wont do, it might take more than that depending on how much it takes to finish the requests you are sending.
If you are looking for Throughput you can add an aggregate report listener which calculates the throughput for you and depending on the results you can configure your thread properties to reach your goal.
Reference :
Jmeter user manual
Following are the params,
in the above scenario, I expect 2 threads but i see 6 threads
below is the output,
Each JMeter thread executes all HTTP Request (or other) samplers under the Thread Group as fast as it cat. How many samplers will be executed given 2 seconds test duration depends on your application response time.
If you need to limit the throughput to certain value (i.e. 1 request per second) you will need to add Constant Throughput Timer to your Test Plan and configure the target throughput to be 60 requests per minute.