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
Related
I'm looking at doing spike tests and I think ultimate thread groups in Jmeter are the way, but I need Jmeter to keep the connections open during the test and use same user on each iteration like it does in regular thread groups, is there a way to force that in Ultimate thread groups as well?
If not, is there a way to do spike testing with regular thread groups in Jmeter?
I've tried setting the thread schedule to produce spikes in ultimate thread group but Jmeter continues to generate new connections per each request. In regular thread groups this can be solved by checking "Use same user on each iteration" but that check box is not present in Ultimate Thread Groups.
I can think of the following options:
Don't use Ultimate Thread Group, the "spike" can be implemented using normal Thread Group in combination with Synchronizing Timer
If you want to proceed with the Ultimate Thread Group you can add a Loop Controller to it and set the desired number of iterations there
More information: Stress Testing, Soak Testing and Spike Testing Best Practices with BlazeMeter
If we want to execute the script for an hour for 5k users, which thread group will fit best? How do I make sure that only 5k users will be injected in whole 1 hour?
Sure you can, this can be implemented using any Thread Group derivative, i.e.
Normal JMeter Thread Group:
Concurrency Thread Group
Ultimate Thread Group
By default you have only option #1, other Thread Groups can be installed using JMeter Plugins Manager
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've got quite complex jmeter test plan that prepares data and save pre-conditions to properties that next thread groups use. So I CANNOT disable "Run thread groups consecutively" and split this onto 2 different plans. But I need to emulate different users' behavior and those thread groups differ by Number of threads and queries.
Is there any way to launch selected thread groups sequentially without breaking preparation on a regular basis?
Will try to do that via setUp Thread Groups/ Thread Groups / TearDown Thread Groups and without Run consecutively
I am have been exploring JMeter for the last couple of days. And I am try to achieve the following:
I am trying to create a load test for a service such that, in the first loop 'n' threads are created and in the second loop 'n+m' threads are created and in the third loop 'n+2m' threads, in the fourth 'n+3m' threads and so on. I did find many solutions here and I tried replicating them, but somehow it is not working for me. The test plan I created looks something like this:
Step 1: Add a user defined variable called USERCOUNT = 0
Step 2: Create a thread group. I have used __intSum to increment USERCOUNT by one and storing the result back in USERCOUNT for future reference.
Ideally what I am expecting here is, in the first loop one thread is created, in second loop 2 thread are created and in the third loop 3 threads are created. So in total there should be 6 thread created. However the results show up something like this:
Not sure if I am missing something silly or my approach itself is completely wrong. Any help from the community would be appreciated. :)
I believe what you are trying to do is impossible. When JMeter starts a thread group for the first time it initializes the number of threads.
What you are essentially trying to do is re-run the same test three times with different numbers of users each time. JMeter cannot re-run a thread group once started, it can only re-run ("loop") a thread in a thread group. It is not possible to add threads to a running thread group once the ramp up and threads are initialized. (Let me know if I should try to explain that further).
If you want one thread group to populate the run-time settings of another thread group, you must have two thread groups in the test plan. At the test plan level, check off the option "Run Thread Groups Sequentially."
With that option, JMeter will not initialize the number of threads on the second thread group until the first one finishes. The first thread group can set a global property, and the second thread group can reference it in the number of threads.
How to set a property in beanshell: (this would be in Thread Group 1)
props.put("threadgroup_2_num_users","15");
How to reference that value in Thread Group 2:
${__P(threadgroup_2_num_users)}
If this does not help, maybe try to describe your end goal. What are you trying to learn about the thing you are testing?
Edit: Perhaps using the plugin package "Stepping Thread Group" will allow you to achieve the scenario you are trying in a single thread group. Check this out:
http://jmeter-plugins.org/wiki/SteppingThreadGroup/
JMeter currently doesn't provide possibility to change number of threads on-the-fly during test execution so I would suggest to go with the following alternatives:
Use i.e. Ultimate Thread Group available via JMeter Plugins which adds some extra features to JMeter's Thread Group so you will be able to implement your scenario
Consider so called "goal oriented scenario" when load is based on requests per second rather than on number of virtual users. You can precisely set desired throughput rate and even change it during test run using Constant Throughput Timer