Best Practice to create Taurus yml for JMeter script containing several thread groups

Question

A JMeter script has been developed as the following:

Test Plan

• Concurrency Thread Group 1 (Target concurrency: ${__tstFeedback(TST Name,1,600,50)})

• Sampler 1

• Sampler 2 (this contains a throughout shaping timer)

• Concurrency Thread Group 2 (Target concurrency: ${__tstFeedback(TST Name,1,100,50)})

• Sampler 1

• Sampler 2 (this contains a throughout shaping timer) . .

For the Taurus yml I have created the following:

settings:
  env:
    jmeterVersion: 5.5
execution:
  - scenario: peak-test
    hold-for: 15m
scenarios:
    peak-test:
       script: testscript.jmx
       modifications:
         disable:
           - Thread Group 2
           - Thread Group 3
           - Thread Group 4
modules:
    memory-xmx: 6G
    detect plugins: true
reporting:
  - module: final-stats
  - module: console

I had a look at several posts online with regards to how to create a Taurus yml with multiple thread groups that have different throughput requirements. My approach with the above yml was to create different yml files for each thread group and disable the thread groups that do not have the same throughput.

Then I would be able to run each yml using the command:

bzt testscript1.yml, testscript2.yml, etc. etc.

Is this the best practice from an implementation perspective?

Answer 1

I amended the scenarios section as per the below:

scenarios:
  peak-test:
    script: APM_Performance_Test_latest.jmx
    variables:
      sender_connections: 100
      receiver_connections: 50
      duration: 900
    modifications:
      thread-groups:
        - name: PDCS Send MQ - CTG
          timers:
            - throughput-shaping:
                startRampUp: 0
                steps:
                  - duration: ${duration}
                    target: 55
                    concurrency: auto
        - name: PNRGOV Send MQ - CTG
          timers:
            - throughput-shaping:
                startRampUp: 0
                steps:
                  - duration: ${duration}
                    target: 55
                    concurrency: auto
        - name: EBORDERS XML Send MQ - CTG
          timers:
            - throughput-shaping:
                startRampUp: 0
                steps:
                  - duration: ${duration}
                    target: 2
                    concurrency: auto

When the TST feedback function was in the script, it didn't look to be working as the throughput and number of threads were not being generated accordingly. The above worked better. Happy to hear feedback on how this could be made more efficient. Thank you.