I am seeing some odd behaviour when running a single jmeter script in which
contains multiple thread groups that I want to use concurrently.
I am using a distributed setup where the master is controlling 4 slaves. Master
and slaves are running on
Ubuntu Server 14.04
openJDK Java version 7u79 also upgraded to 8u92
JMeter version 2.13 r1665067 with xms and xmx set to 16gb
However I get the same behaviour when running locally.
The scripts consist of 1 setup thread group, 3 active thread groups and 2
disabled thread groups which contain shared scripts to be called using module
controllers, I have also moved the shared scripts so each thread group has it's
own copy of the ones they need.
The 3 active thread groups define the number of threads using:
${__P(g1threads,0)}
${__P(g2threads,0)}
${__P(g3threads,0)}
Groups 1 and 2 has a 10 minute rampup, group 3 has a 2 minute rampup.
I then start the script using:
jmeter -n -t <scriptname> -Gg1threads=4000 =Gg2threads=1000
This should start group 1 with 4000 threads per slave and group 2 with 1000 per
slave, group 3 has nothing to start.
This process works fine when only defining the thread counts for 1 group but
when I add multiple groups (as the above example) there is a delay in
subsequent groups being started as well as an unacceptable lag in any 1 thread
group starting. The jmeter-server log shows the following activity:
2017/01/31 14:32:15 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 1 threads 1 ramp-up 1 perThread 1000.0 delayedStart=false
2017/01/31 14:33:50 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 1 threads 4000 ramp-up 600 perThread 150.0 delayedStart=false
2017/01/31 14:41:37 INFO - jmeter.threads.ThreadGroup: Started thread group
number 1
2017/01/31 14:41:37 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 2 threads 1000 ramp-up 600 perThread 600.0 delayedStart=false
2017/01/31 14:44:10 INFO - jmeter.threads.ThreadGroup: Started thread group
number 2
2017/01/31 14:44:10 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 3 threads 0 ramp-up 120 perThread Infinity delayedStart=false
2017/01/31 14:44:10 INFO - jmeter.threads.ThreadGroup: Started thread group
number 3
We can see the startup threadgroup starting at 14:32:15 which also creates a
load of data files and takes 1 1/2 minutes to do so, this is expected. Active
thread group 1 then starts at 14:33:50 and active thread group 2 then starts 8
minutes later as thread group 1 finishes startup.
I need group 2 to start at the same time as group 1 but aware there is an
existing bug associated with this
(https://bz.apache.org/bugzilla/show_bug.cgi?id=58182) so my problem is
squarely focussed on the time the thread group is starting up. I also see for
group 1 that the startup time is not 10 minutes, but closer to 15 which points
to this 8 minute group startup being the problem.
Thread debug logging has shown nothing up of interest, just many many entries
of the below
Subtracting node, stack size = 6
adding controller: org.apache.jmeter.control.LoopController@5f41cacd to sampler
config
A simple script
If I do simplify the first thread group to only contain a single sampler, the
error does not fully replicate itself but there is a 22 second delay instead of
8 minutes but I would still think this too long for a single sampler script.
2017/01/31 15:38:42 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 1 threads 1 ramp-up 1 perThread 1000.0 delayedStart=false
2017/01/31 15:38:42 INFO - jmeter.threads.ThreadGroup: Started thread group
number 1
2017/01/31 15:40:21 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 1 threads 4000 ramp-up 600 perThread 150.0 delayedStart=false
2017/01/31 15:40:43 INFO - jmeter.threads.ThreadGroup: Started thread group
number 1
2017/01/31 15:40:43 INFO - jmeter.threads.ThreadGroup: Starting thread group
number 2 threads 1000 ramp-up 600 perThread 600.0 delayedStart=false
I have also tried this with the thread numbers hard coded instead of the
parameter and changed the order of the thread groups, the second one always
needs to wait until the first one is fully started and the group always takes
longer than expected to start.
Playing with "delay thread creation"
I decided to have a play around with the "delay thread creation" option so I
enabled this setting in thread group 1 only and it seems to be working on some
level but on another level made it much worse.
I can now start up threads on both groups (just a reminder, both groups have a
10 minute ramp up, group 1 has 4000 threads, group 2 has 1000 per box). After
14 minutes it had only been able to start 983 threads out of 4000. Thread group
2 had started 132 out of 1000 and group 1 had started 851 out of 4000.
Using the "Delay" option, instead of it taking 8 minutes to start thread group
1 and 3 minutes to start thread group 2, it took 14 minutes to only start
around a quarter of the required threads for both.
Has anyone seen similar issues before and is there an explanation and
preferably a workaround for it.
Thanks
The information included in this email and any files transmitted with it may
contain information that is confidential and it must not be used by, or its
contents or attachments copied or disclosed to, persons other than the intended
addressee. If you have received this email in error, please notify BJSS. In the
absence of written agreement to the contrary BJSS' relevant standard terms of
contract for any work to be undertaken will apply. Please carry out virus or
such other checks as you consider appropriate in respect of this email. BJSS
does not accept responsibility for any adverse effect upon your system or data
in relation to this email or any files transmitted with it. BJSS Limited, a
company registered in England and Wales (Company Number 2777575), VAT
Registration Number 613295452, Registered Office Address, First Floor, Coronet
House, Queen Street, Leeds, LS1 2TW.
