All Thread Groups do not start at the same time

[asfimport]

indravardhan (Bug 58182):
We have a test plan that has multiple threads groups. Each thread group has same value for ramp up period and test duration(using variables).
Startup delay is provided as 0.

When test starts we notice that all threads groups are started sequentially and this leads to test running for longer duration then expected.
As group which was started late will finish later.

Below is one example.

~> grep "Starting thread group number” *
2015/07/22 03:51:45 INFO - jmeter.threads.ThreadGroup: Starting thread group number 1 threads 31 ramp-up 300 perThread 9677.419 delayedStart=false
2015/07/22 03:52:34 INFO - jmeter.threads.ThreadGroup: Starting thread group number 2 threads 11 ramp-up 300 perThread 27272.727 delayedStart=false
2015/07/22 03:52:50 INFO - jmeter.threads.ThreadGroup: Starting thread group number 3 threads 5 ramp-up 300 perThread 60000.0 delayedStart=false
2015/07/22 03:52:58 INFO - jmeter.threads.ThreadGroup: Starting thread group number 4 threads 2 ramp-up 300 perThread 150000.0 delayedStart=false
2015/07/22 03:53:01 INFO - jmeter.threads.ThreadGroup: Starting thread group number 5 threads 13 ramp-up 300 perThread 23076.924 delayedStart=false
2015/07/22 03:53:20 INFO - jmeter.threads.ThreadGroup: Starting thread group number 6 threads 7 ramp-up 300 perThread 42857.145 delayedStart=false
2015/07/22 03:53:31 INFO - jmeter.threads.ThreadGroup: Starting thread group number 7 threads 5 ramp-up 300 perThread 60000.0 delayedStart=false
2015/07/22 03:53:39 INFO - jmeter.threads.ThreadGroup: Starting thread group number 8 threads 3 ramp-up 300 perThread 100000.0 delayedStart=false
2015/07/22 03:53:44 INFO - jmeter.threads.ThreadGroup: Starting thread group number 9 threads 4 ramp-up 300 perThread 75000.0 delayedStart=false

Below is code snippet from org.apache.jmeter.engine.StandardJMeterEngine#run().

while (running && iter.hasNext()) {// for each thread group
AbstractThreadGroup group = iter.next();
.
.
log.info("Starting ThreadGroup: " + groupCount + " : " + groupName);
startThreadGroup(group, groupCount, searcher, testLevelElements, notifier);
.
.
}

org.apache.jmeter.engine.StandardJMeterEngine#startThreadGroup().
private void startThreadGroup(AbstractThreadGroup group, int groupCount, SearchByClass<?> searcher, List<?> testLevelElements, ListenerNotifier notifier)
{
.
.
group.start(groupCount, notifier, threadGroupTree, this);
}

and ThreadGroup.start() method will spawn all threads for a group. So second group will start once threads are created for first group.

Now one solution I have found is to enable “Delay thread creation until needed” and set startup delay to some value > 0.
This will run new ThreadStarter thread for each group and all groups will start at the same time.

Can we have some option to enable parallel start of all thread groups ?

Votes in Bugzilla: 1
OS: All

Depends on:

• Rampup may not be respected if thread take time to start leading to threads continuing to start post ramp up time #3638

[asfimport]

harsh (migrated from Bugzilla):
We can use countdown latch. Using count-down latch, we can wait all thread group run at same time.

[asfimport]

harsh (migrated from Bugzilla):
We can use countdown latch. Using count-down latch, we can wait all thread group run at same time.

[asfimport]

Stuart Kenworthy (migrated from Bugzilla):
Do we have any movement on this bug? My test rig is currently suffering heavily from this bug and #3638 which is impacting my ability to run multiple thread groups in a planned amount of time.

[asfimport]

@pmouawad (migrated from Bugzilla):
(In reply to Stuart Kenworthy from comment 3)

Do we have any movement on this bug? My test rig is currently suffering
heavily from this bug and
#3638 which is impacting my
ability to run multiple thread groups in a planned amount of time.

Did you try setting delay to something high enough so that all threads are created ?
What is your use case exactly ?
Thanks

[asfimport]

@pmouawad (migrated from Bugzilla):
Setting delay should be a solution since now #3638 is fixed.