JMeter – Understanding the Scope of Variables & Sharing among Threads and Thread-Groups

vIns

8 years ago

In this article, We will see how we could define variables in JMeter in such a way that they can be accessed by

only within the thread
all the threads within thread group
the whole test plan in global scope

Scope: Local to Thread:

Creating Variables at Run Time – Multiple Threads:

By default, creating any new variables are local to a thread. It can not be accessed by other threads in the same thread group / other thread groups in the Test plan. Any change in the value does not get reflected in other threads/groups.

Lets see a simple demo.

I create a simple JMeter test in which I have only Thread Group. I add a JSR223 Sampler.

ctx.getThreadNum() - returns the current thread number. It starts from 0.

I add a condition that I need to create a variable only for the first thread (also knows as first user).
I run the test with 5 users and check the log. Only for the first user, the values is shown as 10 and for the remaining users – it is null!

Above execution result confirms that variables are local to a thread.

Creating Variables at Run Time – Multiple Iterations:

By default, a variable created for a thread retains its value throughout the test (even with multiple iterations) until it is reset.

Lets see a simple test how variables work with iterations.

I add a dummy sampler which gives some random string for every iteration as shown here.

I add a Regular Expression Extractor to extract the value only if the Random String ends with the letter ‘t’.

I print the value extracted (stored in regex.var) using JSR223 post processor.

I run the test for single user with 10 times.

Result:
- For the first iteration, random string does not end with t. So the regex.var is set to null.
- During 2nd iteration, random string ends with ‘t’. so the value is set to the random string generated for the iteration and printed.
- During iteration from 3 to 8, the random string does not end with ‘t’. But the value which was set in the 2nd iteration still is stored in the ‘regex.var’. It is not reset! So beware!
- During iteration 9, another random string is generated which ends with ‘t’. so ‘regex.var’ is reset
- During iteration 10, value is not reset.
In the Regular Expression Extractor , If I use a default value ‘ NOT_SET’ to reset the value everytime. I rerun the test.

So, whenever there is no match, the value is set to ‘NOT_SET’ or any given default value.

Above execution result confirms that variables are local to a thread & they retain the value unless it is reset.

User Defined Variables – Multiple Threads:

Above example explained creating variables at run time and their scope. So, what about User Defined Variables?

I create a User Defined Variable in my test as shown below.

I add a JSR223 sampler to modify the value – I multiply the thread number by 3 and store it in ‘udv.counter’

As expected, all the threads will now have their own copy of udv.counter = 1. during execution, if they are all reset to a different value, then they keep the modified value within the thread scope.

Scope: Global – All Threads in Test Plan:

Sharing Variables Using Properties:

Whenever you need to share the variable among all the threads in the Test Plan, Best way to share it using Properties.

I create a simple test plan – I add a Property File Reader to create some properties for my test plan. The property file contains a property ‘myprop=0’.
I have 4 thread Groups – Each thread Group has 4 users.
I increment the value of myprop by 1 as shown below.

I run the test and check the results. myprop value is increased by every thread and every thread group.

At the end of the test, myprop is set to 16. Any modification to a property gets reflected everywhere in the test plan.

Properties with Objects:

Unlike variables, properties can also store objects.

In a new Test Plan, I add a Setup thread Group, I create a property to store an arraylist.

props.put("mylist", new ArrayList());

Every thread in the thread group add their thread number to the list.

props.get("mylist").add(ctx.getThreadNum());

At the end, I print the value in the list.

log.info(props.get("mylist").toString());

It prints the value as shown here.

Sharing Variables Using bsh.shared Namespace:

bsh.shared is a special static space which is shared across all interpreter instances in beanshell. It can be used like properties.

I can store an object as shown here.

bsh.shared.mylist=new ArrayList();

Adding current thread number to the list

bsh.shared.mylist.add(ctx.getThreadNum());

In the tear down thread group, print using

log.info(bsh.shared.mylist.toString());

Scope: Local to Thread Group:

When you have multiple thread groups in your test plan, sometimes you might want to share the info only among all the threads within the thread group. Not with the threads in the other thread groups!

Creating some variables specific to a thread group, which can be shared by all the threads, can be done using BeanShell Init function.

Uncomment below line in jmeter.properties

beanshell.function.init=BeanShellFunction.bshrc

I add a below function in the BeanShellFunction.bshrc file

int i = 0;

getUpdatedValue(){
  return i++;
}

Now lets create 4 thread groups each with 4 threads.
They all have a beanshell sampler which calls the below statement.

int val = ${__BeanShell(getUpdatedValue())};
log.info("Value : " + val);

For each Thread Group, it prints the value between 0 and 3. Changes are getting reflected to the threads in the Thread Group. But not to the other Thread Group.

Happy Testing & Subscribe 🙂