Max Users adding concurrency values from different scenarios which causes max users to look incorrect.

[Justin]

I'm still learning Taurus/Blazemeter but I came across a discrepancy. I just wanted to see if the test is not setup correctly, or if I'm missing something.

Anyways, right now I have a yaml file with 2 different scenarios. Both scenarios have different concurrency + hold-for values and I've set the test to be sequential. My idea was to create one file where I run scenario 1 with it's execution settings, then scenario 2 is run with a different amount of concurrent users. However, when I look at the report in Blazemeter my max users number seems to be the combined total of users used in both different scenarios. (It'll show 25 users when I have 15 users on scenario 1, and 10 users on scenario 2) I can't seem to find anything in the documentation for this, is this expected? or is there something I can add/modify in the yaml file so that the max users would be 15 in the report, and have it show that it went from 15 to 10 concurrent users?

Thanks,
Justin

[Dmitri T]

Unfortunately we cannot help without seeing your YAML and knowing what are your expectations.

Maybe this configuration will help and you will be able to achieve what you want using it as a basis:

execution:
- concurrency: 10
  hold-for: 20s
  scenario: main
- concurrency: 15
  hold-for: 15s
  scenario: main
  delay: 20s

scenarios:
  main:
    requests:
    - http://blazedemo.com/

It produces workload like this:

By the way, BlazeMeter University offers The Complete Taurus Course for free

[Justin]

Hi Dmitri,

Thanks for the information. That's pretty similar to what I'm trying, here's my yaml:

---
scenarios:
 getStateTypeListData:
    script: (jmx script 1)
 getPatientDetail:
    script: (jmx script 2)

execution:
- concurrency: 10
  hold-for: 3m
  label: getPatientDetail
  scenario: getPatientDetail
  delay: 2m
- concurrency: 15
  hold-for: 2m
  label: getStateTypeListData
  scenario: getStateTypeListData


reporting:
- module: passfail
  criteria:
  - avg-rt >1s, continue as failed

modules:
  local:
    sequential: true  # false by default
  jmeter:
    properties:
        url: (env specific URL)
        filepath: (Path to testData)
        threads: 50
        rampup: 0
        iterations: 20

However, on the report I'm still seeing the max users at 25. I'd expect to see 15 in this scenario as there was never 25 users performing requests at the same time. I'm not sure if I'm missing something here, or why it's reporting that way.

[Dmitri T]

Remove threads: 50  from your config and it should resolve your issue. Otherwise just use my example.

As per Run Existing JMX File chapter

> In case when existing JMX file have multiple thread groups with different concurrency values while yaml config has its own concurrency, the main one in yaml will be divided in proportion to the concurrency values in thread groups. For example, if there are concurrency values 1 and 2 in two thread groups and 30 in yaml, the main will be divided in the ratio of 1:2, which means 10 to the first thread group and 20 to the second.

[Justin]

Thanks again Dmitri. I'm still having the same issue even after removing the threads. I also tried your example case:

---

execution:
- concurrency: 10
  hold-for: 20s
  scenario: main
- concurrency: 15
  hold-for: 15s
  scenario: main
  delay: 20s

scenarios:
  main:
    requests:
    - http://blazedemo.com/

However, I'm getting a different result than what you showed in the screenshot earlier. It's showing 25 max users instead of 15. Any other ideas for this one? Looks like I'm doing exactly what you were and I'm getting a different result.