Excuse my basic jMeter knowledge.
My script has 5 thread groups, one with two threads, three with 1 thread and then the final group with 30 threads. When the final group runs it runs first for 1 thread then when that thread has completed it will run the 30 threads concurrently including that thread 1.
Any clues on how I can get that thread group to kick off with all 30 threads when it starts? Instead of initially with just 1 thread.
Thread group config
Test plan config
Inside the thread group in question there is a double nesting of loop controllers, which seem to work correctly.
Hope you can help thanks.
If i understand your question correctly then in my opinion, there is an option in the Test Plan which says Run Thread Groups consecutively-- Uncheck the same and then execute your run, it should work..!!
You most probably checked by error "Run thread Groups consecutively" option in Test Plan:
Related
I have 4 thread groups in my test. I have requirement as below:
I want first 3 thread groups to work sequentially. Hence, I have checked the chekcbox "Run Thread groups consecutively". But, i want my fourth thread group to start 30 mins after the third thread group while the third thread group is still not complete. Can this be achieved on Jmeter. Any help on this is highly appreciated.
If you tick Run Thread groups consecutively box you won't be able to have more than 1 thread group running at any moment of time.
So you need to untick that box on test plan level and start all Thread Groups in parallel.
The fact that the thread group has started doesn't necessarily mean that it will start executing Samplers, you can delay the execution until the previous Thread Group is done.
For example you can use Inter-Thread Communication Plugin for this purpose, in 1st thread group and put something into a FIFO queue and then try to read the value using jp#gc - Inter-Thread Communication PreProcessor in the 2nd Thread Group (add it to the first sampler). The 2nd Thread Group will start executing samplers only when the value will be available in the queue.
See SynchronizationExample.jmx test plan for example implementation
The same approach should be applied for thread groups 3 and 4, when 3rd thread group starts - put something to the FIFO queue so 4th thread group would be aware that the 3rd one has started, then you can "sleep" for 30 minutes using Flow Control Action sampler
I have two thread group Thread group 1 and Thread group 2 in my test plan. Thread Group 1 has 15 users and Thread Group 2 has 20 users. Now I want to run my thread group 2 after threads ( 15 users) of Thread Group has been started.
Is there anyway to run like this.
To achieve this: use following steps:
Add multiple Thread Group in your Test Plan.
In this example, Thread Group - One has 10 Threads and Thread Group - Two has 1 Thread
To start Thread of Thread Group 2 after all the Threads of Thread Group 1, make sure you keep following settings in Thread Group 2
Check Scheduler check box
Start Up Delay should be greater than Ramp up period of previous Thread Group
Make sure to enter duration as well, otherwise you will get the error.
Add If Controller to first Thread Group and use the following __groovy() function as the condition
${__groovy(ctx.getThreadGroup().numberOfActiveThreads() == ctx.getThreadGroup().numberOfThreads,)}
Now you have a "trigger" which fires when all the threads defined in Thread Group are started. Now you can use i.e. Inter-Thread Communication Plugin in order to "tell" the 2nd Thread Group that it's good to go. Check out SynchronizationPluginsExample.jmx for reference implementation.
Add Startup Delay to group 2 which is greater than Ramp-Up Period of group 1
Make sure Test Plan Run Test Group consecutively check-box is un checked
Lets say we have 2 thread groups, one has 10 threads, another one has 30 threads. I have unchecked "run thread group consecutively". In table results, we see response time of second thread group is more than first threadgroup users.
When threadgroups are arranged other way, it shows reverse. So, whichever is second thread group, its user showing response time more than what is there in first thread group.
When you unchecked the "run thread group consecutively", then both the thread group runs in parallel. Now, based on the number of thread they will send the requests. In your scenario, 2nd thread group has created 30 threads and start sending the request. Now, based on,after how much time the response will come, it is listed in the view result. So, you thread group have more thread and may be getting response faster then thread 1. But, thread 1 is also going to be listed in the view results as shown below;-
Option is unchecked, so parallel running:-
So,in short, if "run thread group consecutively" option is unchecked, thread groups will run in parallel else sequential.
Option is checked, so sequential running:-
Hope this helps.
Only one explanation comes to my mind:
You're running your test in GUI mode
You're running it in GUI mode with Listeners enabled
If above assumptions are correct JMeter is simply lacking resources in order to kick off that many threads and given JMeter is not capable of sending requests fast enough you're getting "false negative" results as JMeter spends time in GC trying to free up some Heap space in order to be able to operate.
So:
Make sure to run your test in command-line non-GUI mode
Disable all the Listeners, they don't add any value, only consume valuable resources
Follow recommendations from the 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure in order to configure JMeter for maximum performance
I want to run a thread x times. The thread group contains three samplers and because I dont want them to be mixed up in the result windows I only want to start the next thread when another is finished. I don't want to use a Ramp-Up Period because a thread could take 1 to 20 seconds.
You could use 3 thread groups and module controller (to referencd in the 2 other thread groups the elements in the first one to avoid copy ) and check on test plan the option:
Run Thread Group sequentially
Your use case is not very clear, however if you need to limit JMeter to X concurrent threads only the most obvious choice would be going for the Concurrency Thread Group
As per Advanced Load Testing Scenarios with JMeter Part 4 - Stepping Thread Group and Concurrency Thread Group article:
The Concurrency Thread Group provides a better simulation of user behaviour because it lets you control the length of your test more easily, and it creates replacement threads in case a thread finishes in the middle of the process.
You can install Concurrency Thread Group as a part of Custom Threads Group bundle using JMeter Plugins Manager
Regarding your three listeners bit, I would recommend reconsidering this approach as per JMeter Best Practices you should not be using any listeners, instead of it you need to run JMeter in non-GUI mode and use -l command-line argument to specify the results file name. Once your test is finished you can open the .jtl results file with a listener of your choice or generate a reporting dashboard from it.
You can use "jp#gc - Ultimate Thread Group". The Ultimate Thread Group provides flexible thread scheduling to your test scenario. It allows us to create a scheduled thread with advanced configuration. Start Threads Count, Initial Delay, Startup Time and Hold Load Time can be defined separately for each record.
You can define tasks to run consecutively.
This platform support flexible thread scheduling. You can read detailed wiki docs about the ultimate thread group.
Link: Loadium.com/wiki/ultimate thread
Basically, I have 30 thread groups in my test plan and I would like to run 8 thread groups at a time consecutively until the test plan is done.
The main test plan options only allow parallel testing of all threads of 1 thread group at a time.
Is there any other way to achieve this apart from segmenting the thread groups in different JMX files or toggling them?
I'm entirely sure what you mean but I'm going to assume you want to run 8 thread groups simultaneously for a certain period, and than start another 8 thread groups and run those for a certain period etc.
You could do this quite easily with the Stepping Thread Group plugin: http://jmeter-plugins.org/wiki/SteppingThreadGroup/. You can adjust each thread group's start and end time.