I'm using a Stepping thread group for a load test
This is the configuration of stepping thread group.
Instead of running for 4 hours, it is stopping after it is run for 17 minutes. What could be the reason?
You can add Runtime Controller as a parent of your test to enforce running time, in your case Runtime in Seconds = 14400 (4 Hours 60*60*4)
You can change the config for the "Stepping thread group" under "threads every" and set the time limit to small value (20 sec) and "Using ramp-up" as total rampup time required(300 sec)
Related
Can you help me to explain relationship between time in Runtime Controller and Ramp_up period value of Thread group?
I tested
Number of Thread: 1
Ramp_Up Period: 1
Loop count: 1
Runtime Controller: 5s
->Elapsed time of current running test: 5s
But with case
Number of Thread: 5
Ramp_Up Period: 5
Loop count: 1
Runtime Controller: 5s
->Elapsed time of current running test: 10s
I don't understand why it become 10s.
Could you help me to explain more?
Ramp up is the time to execute all threads, runtime is controlling each thread execution.
In your case, ramp up 5 seconds means last thread will be executed after 5 seconds. Last thread will enter runtime controller which will run 5 seconds of execution. Thus 10 seconds is the maximum of your execution.
Runtime Controller acts according to JMeter Scoping Rules so it defines how long its children are allowed to run.
Normally you should be using it in conjunction with Loop Count = Forever or -1 on either Thread Group or Loop Controller level.
So
if you want the whole test to run for 5 seconds - use "Scheduler" section of the Thread Group
if you want only certain sampler(s) to run for 5 seconds - put them under the Runtime Controller, however the whole test duration will depend on when the last sampler enters the Runtime Controller
Also be aware that JMeter "asks" threads to stop so it might take some extra time to let them gracefully shut down.
My scenario is I'm running 50 threads for 15 mins and the running 100 threads for 15 mins. The total time of the of the test is 21 mins.
The 50 threads will start running after 10 seconds, slowly ramping up, for 5 mins 50 threads will run simultaneously and then after 5 mins 100 threads with start running slowly with ramping up and run for 15 mins.
After 100 threads finish the 50 threads will continue there running.
The image below will show you the jp#gc thread group
The image will show you the jp#gc ultimate thread group
I only want the responses (maily in graph format ) drilled down to only when 100 users are present, I dont want aggregate of all the soak test.How can this be done? I have also tried loading the jtl.gz file on https://loadosophia.org , it also gives the aggregate reportwhich i dont want.
I only want the specific report of the spike added of 100 users for 15 mins
Please let me know.
Thanks in advance
You can grep your file to only select the interval of time you want and use it to generate file.
Another option is to use this method:
http://www.ubik-ingenierie.com/blog/automatically-generating-nice-graphs-at-end-of-your-load-test-with-apache-jmeter-and-jmeter-plugins/
With this plugin:
http://jmeter-plugins.org/wiki/GraphsGeneratorListener/
And use the fields :
Start Offset
End Offset
Scenario :
a. Ultimate Thread Group : Thread count :100, Startup time : 60, Hold load : 300
b. If there are 10 Http(s) request in the script and each is having 1 sec of constant timer, total constant time value = 10 seconds.
In the above scenario the hold time will become 300 +(100 *10) OR 300 +(10) OR 300 -(100 *10) OR 300 -(10)
Your timers on samplers don't have anything to do with your total test time. So in your above example, it will simply be 60+300 seconds.
When a thread finishes its 10 requests, it will start again. So once your test is ramped up, each thread will execute them 30 times. If you increased your timers, the 10 request would take longer to complete, so fewer iterations of them would be done- but it wouldn't change your duration.
Timers and holdtime works independently, they are not related.
In your example-
Test will start loading Threads as test begins and by end of 60 seconds all 100 threads would be up.
Individual thread execution depends on response of each request sent on server (in your case 10 requests/thread), so constant timer will wait for 1 seconds before sending next request of same thread to server.
So, hold time ensures same 100 users(threads) load on server for specified period. As and when one thread completes its execution cycles (all 10 requests), it will add another thread to maintain same load during test time specified as hold time.
Test will get completed in 30+60 = 90 seconds.
can somebody please advise how to create a jmeter thread properties correctly with the following requirements
55 user a min ramp-up over an hour with a test running for 4 hours.
If you need 55 users added each minute during 1 hour, you set up should look like:
Number of Threads: 3300 (55 users x 60 minutes)
Ramp-up: 3600 (1 hour == 3600 seconds)
Loop Count: Forever
Scheduler -> Duration: 14400 (3600 seconds in hour x 4)
Be aware that 3300 concurrent threads is quite a high load, make sure that you're following recommendations from JMeter Performance and Tuning Tips guide.
If you won't be able to create such a load from a single machine consider Distributed Testing when one JMeter master machine orchestrates several slaves, for instance 3 slaves having 1100 virtual users each.
So you think about something like this setup I show on the screenshot below, isn't ot? It is set on jp#gc - Stepping Thread Group that comes with jmeter plugins in standard set. You have there 55 users tat will ramp up to that value through 3600 seconds and will hold that load for next 3 hours (10800 sec).
I am performing load test with these parameters :
threads=4
ramp_up_period=90
loop_count=60
So according to above numbers, my assumption is that each one of the four thread will be created in 22.25 seconds and this 4 thread cycle will be repeated 60 times.
Below is the load test summarized report :
According to JMeter manual ramp up period is :
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up
period is 100 seconds, then JMeter will take 100 seconds to get all 10
threads up and running. Each thread will start 10 (100/10) seconds
after the previous thread was begun. If there are 30 threads and a
ramp-up period of 120 seconds, then each successive thread will be
delayed by 4 seconds.
So according to above scenarios approximate total time for executing load test with mentioned thread group parameters is :
TotalTime = ramp_up_period*loop_count
which in my case evaluates to 90*60 = 5400 seconds, but according to summariser Total Time is coming 74 seconds
JMeter version is 2.11.
Is there is any problem in my understanding or there is some issue with JMeter ?
Initially JMeter will start 1 thread which will be doing something, which is under your Loop Controller. In 30 seconds second thread will join, in 30 more seconds 3rd thread will start and finally on 90th second 4th thread will start.
Starting from 90 second 4 threads will be doing "what is under your loop controller".
There is no way to determine how long it would take, especially under the load. If you need a load test to last approximately N seconds you can use Duration input under Sheduler in Thread Group.
If you want to forcefully stop the test if certain conditions are met there are 2 more options:
Use Test Action Sampler
Use Beanshell Sampler
Example Beanshell code (assumed to be run in separate thread group in endless loop with reasonable delay between firing events)
if (currenttime - teststart > Long.parseLong(props.get("test_run_time").toString())) {
try {
DatagramSocket socket = new DatagramSocket();
byte[] buf = "StopTestNow".getBytes("ASCII");
InetAddress address = InetAddress.getByName("localhost");
DatagramPacket packet = new DatagramPacket(buf, buf.length, address, 4445);
socket.send(packet);
socket.close();
} catch (Throwable ex) {
}
}
TotalTime would be that if you were working without concurrency. When working in a multi-threaded environment it can happen that thread 1 is already performing its second call when thread 3 is still firing up.