Add support for the User Parameters preprocessor

[Melanie-RK]

Request: Add support for the User Parameters preprocessor

Use case: I have a JMeter test plan that uses User Parameters because the value needs to be different on each iteration. Due to the small size of the test, it performs better with User Parameters than with a csv data source.

[rabelenda]

Hello, thanks to ask for this. We need to identify what is the best way to implement this.

Do you use this component just because it is more performant than csvDataset? If csvDataset were as performant as this solution, would you prefer it instead (specifying values through CSV instead of java api method invocations)?

Some potential options that come to my mind are:

• Extendingvars set method to support setting values per thread. Eg:

  vars()
  .set("var1", "val11", "val12", "val13")
  .set("var2", "val21", "val22", "val32")

  This would be pretty easy to implement, short syntax, but may be a little confusing for users.

• Adding a method to csvDataset, to make it more performant. Eg:

  csvDataset("myData.csv")
  .perload()

  This would require users to always use a csv, and would require more code changes (probably a new test element), but would provide a simple way to change data (is simpler to modify data in a csv than in actual code) and would probably be more intuitive to users (when working with multi thread data just use csvDataset, otherwise just define a var).

• Create a new test element just for user parameters. eg:

  userParameters()
  .param("var1", "val11", "val12", "val13")
  .param("var2", "val21", "val22", "val32")

  If possible I would avoid this to avoid adding even more concepts making API entry point even more complex, harder to search, etc. The only advantage I see to this one is that is clearly identifiable to existing JMeter Users, but I think the other approaches would be better in the long term both for people with and without JMeter knowledge.

Anyone has any other alternatives, proposals or comments?

[Melanie-RK]

Do you use this component just because it is more performant than csvDataset? If csvDataset were as performant as this solution, would you prefer it instead (specifying values through CSV instead of java api method invocations)?

I use this component because it's more performant than the alternatives. If other methods to achieve the same goal were just as performant, I would use the one that is the easiest to use.

[poyun]

Hello, thanks to ask for this. We need to identify what is the best way to implement this.

Do you use this component just because it is more performant than csvDataset? If csvDataset were as performant as this solution, would you prefer it instead (specifying values through CSV instead of java api method invocations)?

I hope to have a method to replace 'csvDataset' because my custom data sources may come from MySQL, code-generated data, rather than being limited to CSV files.