I am literally new to Jmeter and have just started exploring the tool. I am developing tests to perform load and stress test on a website where the peak load is 10000 users an hour. The stats are something like:
Hour
Index Users
0 2,728
1 1,656
2 1,123
3 1,058
4 1,174
5 1,710
6 3,524
7 5,808
8 7,505
9 8,432
10 9,113
11 9,577
12 9,814
13 9,674
14 10,028
15 9,781
16 8,445
17 8,156
18 6,193
19 6,175
20 5,922
21 5,641
22 4,694
23 3,068
I want to use the ramp up and ramp down feature along with Spike in load but unsure which thread group should i use? The Ultimate Thread group or the Stepping Thread group. Also unsure of how should i configure these thread groups. Any pointers would be greatly helpful.
Thanks in anticipation.
As per Stepping Thread Group documentation
This plugin is deprecated and should not be used. Use Concurrency Thread Group instead.
So Stepping Thread Group doesn't come into play.
Now you need to make a choice between Ultimate Thread Group and Concurrency Thread Group which should be simple as:
Ultimate Thread Group is about threads (or virtual users) which seems to be more applicable for your case
Concurrency Thread Group is about concurrency (or requests per second) which is very useful when you need to generate certain throughput in terms of hits per second rather than need to mimic certain amount of virtual users.
So I would go for the Ultimate Thread Group. With regards to "how to configure" - just use the above values as they are, example configuration for first 8 hours would be something like:
You can install Ultimate Thread Group using JMeter Plugins Manager.
Related
am running test in duration based scenario with jmeter 5.4.1, at the end of the script, test is getting stop prematurely without executing some of the calls in the last iteration, please help me to make sure all the calls executed in the last iteration, i have tried loop,duration controller nothing seems. to be prominent
Example: i have home, login, search,select item & logout, duration of 5 min with 1 user
Test execution : Home 10 login 10 search 9 select item 9 logout 9
Test execution : Home 10
login 10
search 9
select item 9
logout 9
If you set duration in the Thread Group or in Runtime Controller it doesn't guarantee that all Sampler will be executed equal number of times, when the duration is reached or exceeded JMeter will start shutting down the threads (virtual users) and the total number of sample results will mainly depend on the application response time.
So if you want to execute everything 10 times only - set number of loops in the Thread Group to 10 and either increase or remove the duration.
Alternatively you can use Concurrency Thread Group configured like:
this way 1 user will execute samplers for 5 minutes as fast as it can but not more than 10 times.
I want to simulate 100 rps for the application which I am working on. I am planning to use Concurrency Thread Group and Throughput shaping timer. I have created a sample example to test how it works. Below is my script
I have added this as the next line to log4j2.xml file:
<Logger name="kg.apc.jmeter.timers.VariableThroughputTimer" level="debug" />
jmeter.log has below logs
2021-07-21 14:11:22,402 INFO c.b.j.c.VirtualUserController: Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,402 INFO o.a.j.t.JMeterThread: Thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,402 INFO o.a.j.t.JMeterThread: Thread finished: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,407 DEBUG k.a.j.t.VariableThroughputTimer: Calculating 407 380.0 38
2021-07-21 14:11:22,427 INFO c.b.j.c.VirtualUserController: Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-218
2021-07-21 14:11:22,427 INFO o.a.j.t.JMeterThread: Thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-218
2021-07-21 14:11:22,427 INFO o.a.j.t.JMeterThread: Thread finished: bzm - Concurrency Thread Group-ThreadStarter 1-218
........
........
2021-07-21 14:11:23,007 DEBUG k.a.j.t.VariableThroughputTimer: Second changed 60.0 , waiting: 0, samples sent 94, current rps: 100.0 rps
2021-07-21 14:11:23,007 WARN k.a.j.t.VariableThroughputTimer: No free threads available in current Thread Group bzm - Concurrency Thread Group, made 94 samples/s for expected rps 100.0 samples/s, increase your number of threads
2021-07-21 14:11:23,007 DEBUG k.a.j.t.VariableThroughputTimer: Calculating 7 0.0 0
My question is
Q1. Have I configured my test correctly to simulate throughput of 100 rps or am I missing something ?
Q2. How do I calculate in advance how many users do I need to add in Target Concurrency? If I go with the formula
(rps * Maximum response time) / 1000
Here, do I need to add the Maximum response time of all the samplers from 1 to 6? or how?
Q3. How do we calculate the throughput?(refer 3rd image having Aggregate Report),
Is the Total Throughput = Adding Throughput of Sampler 1 to 6, which is = (15.8 + 15.8 + 15.8 + 15.7 + 15.6 + 15.6) = 94.3 rps. Is my calculation correct?
Q4. In the jmeter.log, it says "Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217".
Does that mean number of threads(users) needed to simulate 100 rps are more and hence jmeter needs to decrease the threads(users)?
Then again in the logs, it says, "No free threads available in current Thread Group bzm - Concurrency Thread Group, made 94 samples/s for expected rps 100.0 samples/s, increase your number of threads"
Is it asking me (the user) to increase the thread or it is just the jmeter talking to itself? Jmeter already has 150 threads to use. Actually I started from 50 and then also I received the message to increase the no of threads then I increased the threads to 100 and I got the same message and then finally I increased it to 150 and still getting that message in the logs?
As you can see for the above image, at the 51th second, jmeter was using only 29 threads(users) out of 150. Which means it still has 121 threads left to use. Also, I observed that when I started the script, immediately 150 threads were in use but then they started rapidly decreasing and increasing. However, they never been to 150 during the 60 seconds run (150 threads wered used only at the start, for a fraction of seconds and then got reduced!)
Then why was the message in the logs to increase the users? infact there are users available which jmeter can use?
You only forgot to ask the "Q5": the Ultimate Question of Life, the Universe, and Everything
Q1. We don't know, it depends on the application response time, your 150 threads may or may not be sufficient to conduct the load of 100 requests per second
Q2. Go for the largest response time ever, according to JMeter threads model each thread waits for the previous request to finish before starting the next one so the whole sequence of 6 samplers will act at the speed of the slowest one.
Q3. Throughput Shaping Timer tries to reach and maintain the defined throughput for all the samplers in its scope so if you have 6 requests in scope the throughput for individual request would be 100 / 6
Q4. Need to decrease concurrency - the timer is "talking to itself" informing that it goes too fast hence need to shut down a couple of threads to slow down the requests rate. increase your number of threads is for you but I don't think it's applicable for your case, if you run the real test and will see tons of messages like this in the log it will indicate that the current amount is not sufficient to reach the target throughput
Don't run your test in GUI mode, it's only for tests development and debugging, when it comes to execution you must be using command-line non-GUI mode
According to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.4.1 or whatever is the latest stable version available at JMeter Downloads page
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)
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
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).