I need to run a load test of 25 threads, what will be the most efficient configuration to use? (ramp-up period....). I ran the load test with the below configuration and some of the threads failed but pass if I just ran the script individually.
Your configuration will mean that:
JMeter start with 1 thread and add another thread each 4 seconds
Once started each thread will begin to execute Samplers upside down (or according to the logic controllers)
When the thread executes the last sampler it will be shut down
When the last thread executes the last sampler the test ends
Depending on the number of samplers and application response time you may or may not achieve 25 users concurrency, you might want to check the actual number of concurrent users using Active Threads Over Time listener
If you want to make sure to have 25 online users set "Loop Count" to Infinite and "Specify Thread Lifetime" duration to be more than your ramp-up period. See JMeter Test Results: Why the Actual Users Number is Lower than Expected article for more details.
With regards to the failures - we cannot state anything meaningful without seeing request and response details, make sure to save them using i.e. View Results Tree listener and inspect response body for the failed requests
Related
I want to achieve the throughput 7.6 requests per second.
I am using bzm- Concurrency Thread Group with Feedback function and Throughput shaping timer as below. Please ignore the thread groups which are striked out. They are disabled and are not executed by Jmeter.
When I run the script from command line, it shows the logs as below
And in the log file, it mentions that:
In the Concurrency Thread Group, I have defined Target Concurrency with a Feedback function as ${__tstFeedback(tst-name,1,100,30)}
Here, 1 and 100 are starting threads and max allowed threads, 30 is how many spare threads to keep in thread pool.
My first question is:
Q1. Why in the command line logs it says that no free threads are available in the current thread group. As you can see from the command line, only 39 threads started. I have defined max allowed threads as 100. On the top of that 30 are kept in the thread pool so that Jmeter can use them if 100 threads are not enough. I also tried increasing the number of threads by passing ${__tstFeedback(tst-name,1,200,30)} , but still I get the same error.
Still why does it say in the logs that no free threads available and hence increase your number of threads?
Also, as you can see from the Summary report, Transaction Controller for Scenario 3 and Scenario 4 are not executed by Jmeter
Q2. What could be the reason that Scenario 3 and Scenario 4 are not executed by Jmeter?
Q1 the warning is being written in 6 milliseconds after test start when only 1 thread was running, do you really expect that 1 thread can conduct the load of 7.6 requests per second? I mean theoretically it's possible, if your application response time is below 130 ms, however I don't think it's applicable for your case, try starting with i.e. 30 threads and remove these ramp-up period and steps.
Q2 we don't know, most probably the reason is that your test doesn't run long enough so first thread isn't able to execute all samplers in scenarios 1 and 2 or there are some Logic Controllers which prevent these scenarios execution or there is a Flow Control Action sampler which doesn't allow the thread to go further, etc.
The answers are always in jmeter.log file, you might also want to increase the JMeter log level for the Throughput Shaping Timer by adding the next line to log4j2.xml file:
<Logger name="kg.apc.jmeter.timers.VariableThroughputTimer" level="debug" />
I have executed couple of Jmeter tests so far. My test plan in very basic one. I'm using Jmeter 5.2 on mac environment.
Number of threads: 500
Ramp-up period: 1
Loop count 3
[x] Same user on each iteration
[ ] Delay thread creation until needed
[ ] Specify thread life time
Basically according to my configuration above, the test will have 500 different threads being spawned in my JVM while this load test is running.
In order to create 500 threads, Jmeter has time restriction of just 1 second only. So, it will create the one thread in each 0.002 seconds from the moment I start the test.
I'm just hitting to an deployed publicly available service with HTTP POST request with a valid payload.
Now my real question
It is possible that the very first request that Jmeter sends will get the response from the server in just 0.2 seconds(200ms). What happens to that thread from that moment? Will this thread being killed after that?
Ramp up period doesn't stop thread, setting Duration will stop(/kill) thread if reach duration time,
Each thread execute independently until it finishes his last loop,
So in your case each thread will end after ~0.6 seconds (0.2 second per request * 3 loops)
It is possible that the very first request that Jmeter sends will get the response from the server in just 0.2 seconds(200ms) - yes, it may be even less, the question is whether your application can respond in 200 ms or less
What happens to that thread from that moment? Will this thread being killed after that? - for particular your set up if there are no more Samplers to execute the thread will execute this HTTP Request sampler 2 more times and after that it will be asked to stop.
You can increase JMeter logging verbosity to whatever level of details you want and inspect jmeter.log file in order to get the idea regarding what's going on under the hood of JMeter. Basic details can be obtained without any configuration tweaks:
This is regarding JMeter
I have a thread group where number of threads is 100. I get response for all the 100 requests in say 3 minutes. However when I generate html report from the .jtl file, it still shows around 50 threads as active even after 6 to 7 minutes.
I was expecting that the active threads would also die out once the response is received. Should we kill/release threads or do we have a similar option in JMeter which I am missing. Can someone advise please.
If you have only 1 loop in Thread Group - each thread (virtual user) should be terminated once it finishes execution of all the Samplers, assuming you don't have i.e. Loop Controller or While Controller or Runtime Controller which may (and will) "hold" the threads alive.
Also make sure to follow recommendations from 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article, in particular:
Run your test in non-GUI mode
Remove all the Listeners from the Test plan
If the issue persists - check jmeter.log file and take the thread dump to identify what exactly JMeter threads are doing.
i am running a simple test with 10 users for 5 mins. my test has a single thread and different transactions within it. By the end of the test, there is a different number of samples for each transaction. Is there a way or a setting so that we don't start any new thread when the test is finishing, i tried ultimate thread group plugin with ramp down , hoping to see same samples for all requests but it didn't happen. Not sure if that is even possible.
Each JMeter thread (virtual user) executes Samplers upside down (or according to the Logic Controllers)
When you're defining test duration it might be the case that some virtual users are somewhere in the "middle" of the Samplers and they stop when they receive shutdown signal.
It means that the very first sampler will be executed with 100% of users and for further samplers the chance of getting executed becomes lower and lower.
The only way to have the same number of Sample Results for all Samplers is using normal JMeter Thread Group and providing fixed amount of loops.
Given above setup you will have strictly 80 executions of each and every Sampler in the Test Plan
More information: Getting Started with JMeter - A Basic Tutorial
I have written a simple test plan with the following steps
Test Plan
View Results in Table
Aggregate Report
Thread group
Threads: 5
Ramp-up period: 0s
Loop count: 1
Inside Thread Group
A dummy sampler to prove that all threads are running concurrently
HTTP request to upload a file
When I run the above tests, the dummy sampler is executed nearly the same time. However, I realize that only 1 thread can execute the HTTP request to upload file at a time, even when I have multiple threads. So the final result will be Thread 1 upload file -> finish -> Thread 2 upload file ... e.t.c.
Is this a normal behaviour and can I make file upload performs concurrently from multiple threads?
It depends on the number of threads, loop count and ramp-up period. JMeter starts threads within the time frame you specify in "Ramp-up period" input and the threads start executing samplers upside down (or according to the Logic Controllers). When there are no samplers to execute or loops to iterate the thread is being shut down.
If you need to configure JMeter to execute a certain request at exactly the same time by several threads add Synchronizing Timer as a child of this request and configure "Number of Simulated Users to Group by" setting to match the number of simultaneous users
Example execution:
As you can see, Dummy Samplers were started in 2 seconds while HTTP Request samplers were executed at nearly the same moment.
See Using the JMeter Synchronizing Timer article for more information on implementing these "rendezvous points" in JMeter tests