My Requirement is to execute 10 request per second for 5 minutes. The configuration I have used is
Thread Group Properties:
number of threads : 600
ramp up period : 60
Loop count : 5,
Add Sampler -> Flow Control Action
Select Logical Action on thread as Pause
Duration(milliseconds) :60000
I used the below command to run jmx from command line to generate xls and generate html report.
/jmeter.sh -n -t demo.jmx -l demo.xls -e -o ./report
Need to know if the configuration I have mapped is correct or not?
I have also looked at constant throughput timer and Runtime controller to stop the execution after 5 mins?
I am not able to validate the end result?
You can see what actual throughput your test generated using Transactions Per Second listener or the relevant chart in the HTML Reporting Dashboard
With regards to configuring JMeter for sending 10 requests per second for 5 minutes I would rather recommend going for Concurrency Thread Group and Throughput Shaping Timer combination.
Configurations:
Related
When number of threads (users): is set below 10, the number of samples is displayed correctly. When number of threads (users): is set to 10, the number of samples is 18 ~ 20.The expected result should be 22. Please point out the problem for me.
JMeter version: 5.4.3
The script settings are as follows:
-- Thread Group
-- Thread Properties
Number of Threads （users）：11
Ramp-up period （seconds）：2
Loop Count:Infinite 2
-- Critical Section Controller
--HTTP Request 1
--HTTP Request 2
--HTTP Request 3
--HTTP Request 4
--HTTP Request 5
-- Aggregate Report # Samples
--HTTP Request 20
--HTTP Request 20
--HTTP Request 19
--HTTP Request 18
--HTTP Request 18
I cannot reproduce your issue:
and I can think of the following reasons:
You have artificial limitation of the test execution time in Thread Group:
You have responses filtering configured in the Aggregate Report listener, i.e. if this box is ticked - you will see only requests which were successful and failed ones won't be displayed:
Try re-running your JMeter test in command-line non-GUI mode and see how many results are in the .jtl results file
Check jmeter.log file for any suspicious entries
And last but not the least, do you realize the concept of the Critical Section Controller? In your setup it means "no concurrency", all HTTP Request samplers will be executed by one thread at a time only so the equivalent setup would be
i set up a 16-hour soak test in jmeter. use a csv file for different users for 10000 users. use ultimate thread group with these settings:
one row
start threads count: 20
initial delay: 0
start up time : 60 sec
hold for load : 57600 sec
shut down time : 10
i run the test 3 times. all of them ended in 8-9 hours.
on the server pc, i look for some settings of iis but didnt see anything.
the second day, in view result tree there was a response such that:
sampler result page
response message: non http response message: en established comnection was aborted by the software in your host machine.
does jmeter any limitation or iis have some timeout value?
JMeter doesn't have any internal "timeouts" for the test, it might be the case you test has.
For example I can think of 2 possible options:
Your CSV Data Set Config has either Recycle on EOF set to True or Stop thread on EOF set to False so when all 10000 lines are used the test stops
Your Ultimate Thread Group is configured to Stop Thread or Stop Test on the error and your test terminates when error occurs
The exact reason for stopping the test can be found in the jmeter.log file
Pardon me if this is already answered (newbie to JMeter).
I have a situation where, I have to read 100,000 URLs from a CSV file but all the URLs should only be run once, along with achieving 500 req/sec load on server. Tried using Once Only Controller with a Thread count of 100, but every thread read only one URL and stops after reading first 100 URLs.
My CSV file looks like this:
URL1
URL2
...
URL100000
I have called my HTTP sampler inside Once Only Controller
Is there something that I am doing wrong here ??
Use the Constant throughput timer(req/min) to have your desired TPS (req/sec)
your TPS will be proportional to the number of active threads.
Ref: https://www.blazemeter.com/blog/how-use-jmeters-throughput-constant-timer.
Do not use Only Once Controller . It will run the thread(100 in your case) only once(each thread hits 1 URL and exits) . Rather use a HTTP Request.
You can do this using Throughput shaping timer.
First in your CSV Config Make sure you set recycle on EOF to false, which means that if JMeter reads all lines it wont start from beginning again.
Add a throughput shaping timer to your http request and mention start RPS as 500 end RPS ass 500 and duration 200 seconds
That means you are telling JMeter to hit 100000 requests in 200 seconds (500 per second * 200 seconds=10000 requets).
To calculate thread pool size use the formula rps*Max response time/1000, Add some extra threads to this value .
For more info on throughput shaping timer please follow this link
I'm creating a small test using JMeter. So far I have one Thread Group that executes an HTTP request, waits for 10 seconds, then executes an other HTTP Request and checks what was returned. If I start 100 such threads with 1 second ramp-up period from the JMeter GUI, it works fine, I get the expected values and the whole test finishes in 22 seconds. However, when I start the very same jmx file from the command line, the test runs for more than 120 seconds and some threads (at the last run, 36 out of the 100) don't get the expected value. This might indicate a bug in the system I test, but I don't understand why the test takes that long time from the CLI and why I get errors from the CLI. What is the difference between running the test from the GUI and from the CLI? Does the CLI run the tests "more parallel"? By the way, this is the command line I'm using:
/home/nar/apache-jmeter-3.3/bin/jmeter -n -t test_transactions.jmx -l test_transactions.out
I'm afraid I cannot share the test plan, but I can share the "outline":
+ Thread Group
+ CSV Data Set Config
+ HTTP Request
| + JSON Extractor
+ Constant timer
+ HTTP Request
| + JSON Extractor
| + Response Assertion
+ View Results Tree
+ Save Responses to a file
+ View Results in Table
+ Summary Report
The Constant timer waits for 10 seconds. The first HTTP Request sends in some data and initiates a computation, the second checks the result.
I think you should disable the following listeners in non gui test:
View Results Tree
Save Responses to a file
View Results in Table
Summary Report
After disable you still have result using -l test_transactions.out which you can later view using GUI mode with Browse button in your Listener
In non GUI you can also generate dashboard report if you want by adding -e -o /path/dashboardfolder
It actually does indicate the bug in the system under test. The reason is that you must run JMeter in non-GUI mode as GUI creates huge overhead in terms of resources consumption, especially when you're using Listeners, especially if one of them is View Results Tree.
So my expectation is that in non-GUI mode you're basically creating more immense load which your application cannot handle. You can check this out using i.e. Active Threads Over Time and Transactions Per Second listeners.
I am currently using JMeter to simulate 5 users firing requests every 40 seconds. I have created 100 different requests but after every 40 seconds, each user is firing all 100 requests. I want to make it in such a way that after every 40 seconds, each user only fires 1 request and that request has to be different from the previous request. I would like to know what kind of controller to use (or anything else) to achieve this scenario.
Thanks
Try to use Random Controller.
The simplest way to implement your scenario:
Thread Group
Number of Threads = 5
Loop Count = N
. . .
Random Controller
HTTP Request 001
HTTP Request 002
HTTP Request 003
. . .
. . .
HTTP Request 100
Test Action
Target = Current Thread
Action = Pause
Duration = 40000
. . .
This will iterate 5 threads N times.
Random Controller will RANDOMLY pick up on each step http request from "requests pool" - all the samplers added as children to Random Controller.
Test Action will pause thread for 40 secs.
Updated:
working illustration for above scheme:
Thread Group
Number of Threads = 5
Ramp-Up Period = 0
Loop Count = 10
Constant Timer
Thread Delay (in ms) = 40000
You can download working example for described scheme from here: rc-plan.jmx.
This one works how you want (at least for me, Jmeter 2.5.1): it picks randomly ONE request from requests pool (in example - 10 requests) for EACH user (here - 5 users) on EACH step (here - 10 loops) and pauses each thread for 40 secs (Constant Timer).
You can also look into this mailing archive: Is their a way to randomize URL selection?.
Situation similar to your one seems to be described here.
...As per official documentation "Interactions between multiple controllers can yield complex behavior. This is particularly true of the Random Controller."
Another option for you may be to create a CSV file with parameters for your requests ahead of time and use CSV Data Set Config to parameterize a single http request.
That obviously depends on how different your http requests are, but if it fits your requirements there are some potential bonuses with maintaining 1 http request in your test plan vs. 100.
The other details would be the same as #Alies Belik laid out -- one thread group configured for your required number of threads and loops, with a constant timer at the end for your 40 second pause.