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" />
Related
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
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 want to understand the relation between Stepping up Thread Groups and Number of Samples.
Stepping Thread Group
My Test Plan looks like this:
Test Plan
But in the Summary report I am getting #Samples more than 10 for certain Requests. Not able to understand how is it working.
The actual number of Sample Results will not necessarily be 10 as:
JMeter starts 1 thread each 2 second until the number of threads will be 10
Once started thread starts executing Samplers upside down
When thread finishes executing Samplers and 60 seconds of duration has not yet passed the threads starts over
So the actual number of Samplers which will be executed in 60 seconds by 10 threads will depend mostly on your application response time.
Check out What is the Relationship Between Users and Hits Per Second? article to learn more about correlation of number of virtual users and delivered load
I have the following
but when I run this with 60 threads I don't see the threads being fired off every second. Instead it seems like the requests in the transaction controller are fired off at a rate of 60 requests per min.
Is there a way I can have JMeter create threads at the rate of 60 per minute without a limit on requests?
You need to use Rampup duration in that case. Again that is one time activity, once threads are created they will execute the request and will die / repeat if you need.
Ultimate Threadgroup plugin is also helpful here.
Generally everybody is interested how much throughput(req per unit time) can server take. So in your case its doing correct job i.e. sending requests 60 per sec.
In practice creating multiple threads per sec is bad practice and IMO such testing is not useful (Why it is required?) because client threads in JMeter is not important but requests sent to server by threads (can be 1-10 or 100) many times and how server responds is important.
If your use case is different then share it in detail and we'll discuss. Hope this helps.
If you want JMeter to kick off one thread per second you need to specify Ramp-Up Period equal to the number of threads (virtual users) under Thread Group, if you want 60 virtual users - go for 60 seconds ramp-up.
Also make sure you allow your Thread Group to loop forever as if you don't - you will run into a situation when some threads have already done their job and some haven't been started yet.
Example configuration:
Example output:
More information: JMeter Ramp-Up - The Ultimate Guide
I am working on stress test, but my first sampler floods server with tons of requests with very little amount of time, so I want to make a delay between each thread using request.
Test structure:
Thread1 - Sampler1 (for example: access login form)
Delay (custom seconds)
Thread2 - Sampler1 (for example: access login form)
Delay (custom seconds)
ThreadN - Sampler1 (for example: access login form)
Delay (custom seconds)
Thread1 - Sampler2
Delay (custom seconds)
Thread2 - Sampler2
Delay (custom seconds)
<...>
Synchronizing Timer
All threads realeased with final sampler (this part works)
I tried to put timers as samplers parents or childs. Probably I am missing something, because non of the timers are working for me.
I've found similar problem solutions, but non of the worked for me:
JMeter - sharing a delay between requests across multiple ThreadGroups
Delays for each thread in Ultimate Thread Group
I would suggest using the stepping thread group via http://jmeter-plugins.org/wiki/SteppingThreadGroup/.
In the 'thread scheduling parameters' section, you'll note you're able to specify the maximum number of threads to run at peak, but you're also also to slowly instantiate threads as you need them.
Very plainly, the setup below says "When I run this test, I'm eventually going to want 100 threads, but when I first start the test, wait 15 seconds, then only start 10 threads. Then add another 10 threads every 120 seconds. Once we reach max threads, keep working for 180 seconds, then slowly peel off 5 threads every 15 seconds.
This should meet your need.
As per your Test Plan description, you can use 1 of the timers mentioned below:
Gaussian Random Timer
Constant Timer
Hope this will help..
Constant Timer would be best option as per your mentioned requirement.
You can use 'Ultimate Thread Group' instead of regular Thread Group. There is 'Initial Delay' in ultimate thread group which will help you to achieve your requirement.