Ultimate Thread Group Converted to Standard Thread Group on Blazemeter Cloud

[Vijayasri T]

Summary

When running JMeter tests with Ultimate Thread Groups (jp@gc plugin) on Blazemeter cloud using provisioning: cloud, the Ultimate Thread Groups are converted to standard Thread Groups. This conversion does NOT occur when running locally, even with an identical Taurus configuration and force-ctg: false setting.

Environment

·      Taurus Version: 1.16.45

·      JMeter Version: 5.6.3

·      Plugin: jpgc-casutg 3.1.1 (Ultimate Thread Group)

·      Issue occurs on: Blazemeter cloud execution (provisioning: cloud)

·      Works correctly on: Local execution

Expected Behavior

When modules.jmeter.force-ctg: false is set, the Ultimate Thread Group should be preserved as-is in the JMX file on both local and cloud execution, allowing it to control its own load pattern through properties: - num_of_threads - startup_delay - ramp_up_time - test_duration - shutdown_time

Actual Behavior Local Execution ✅

When running bzt scenario-medium.yml locally, the Ultimate Thread Group is preserved correctly.

Cloud Execution ❌

When running with provisioning: cloud on Blazemeter, the Ultimate Thread Group (kg.apc.jmeter.threads.UltimateThreadGroup) is converted to a standard Thread Group (ThreadGroup) with approximated values, losing the precise control over startup delay and shutdown time.

Evidence from modified JMX:

Original JMX:

<kg.apc.jmeter.threads.UltimateThreadGroup guiclass="kg.apc.jmeter.threads.UltimateThreadGroupGui"
    testclass="kg.apc.jmeter.threads.UltimateThreadGroup"
    testname="Demo Ultimate Thread Group">
  <collectionProp name="ultimatethreadgroupdata">
    <collectionProp name="-585912703">
      <stringProp name="836285858">${__P(num_of_threads,1)}</stringProp>
      <stringProp name="503236978">${__P(startup_delay,10)}</stringProp>
      <stringProp name="-136992950">${__P(ramp_up_time,20)}</stringProp>
      <stringProp name="1934736355">${__P(test_duration,60)}</stringProp>
      <stringProp name="-284076552">${__P(shutdown_time,10)}</stringProp>
    </collectionProp>
  </collectionProp>
</kg.apc.jmeter.threads.UltimateThreadGroup>

After Taurus Processing (modified_*.jmx):

<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Demo Ultimate Thread Group">
  <stringProp name="ThreadGroup.num_threads">1</stringProp>
  <stringProp name="ThreadGroup.ramp_time">20</stringProp>
  <stringProp name="ThreadGroup.duration">60</stringProp>  <!-- Calculated: test_duration + shutdown_time + startup_delay -->
  <boolProp name="ThreadGroup.scheduler">true</boolProp>
</ThreadGroup>

 

The execution-level load parameters (concurrency, ramp-up, hold-for) are not being specified in the YAML configuration. Instead, we need the JMeter properties set in YAML to override in values set in the JMX file for the Ultimate Thread Group.

Please advise if there’s a configuration option to preserve Ultimate Thread Groups when using provisioning: cloud.

 

Attachments

1.        DemoTest.jmx - Original JMX file with Ultimate Thread Group

2.        scenario-medium.yml - Taurus configuration with provisioning: cloud

3.        artifacts folder – Downloaded from Blazemeter Logs

[Dmitri T]

Hi Vijay, 

I believe the best option is opening a BlazeMeter Support Ticket, I can only confirm the behaviour you've described. 

[Vijayasri T]

Ok thanks. I've logged a Blazemeter Support Ticket.