Using JMeter Functions - Part II

In our previous post related to using functions, we covered the top 3 most commonly used JMeter functions: __log(), __BeanShell() and__RandomString().

Today we've got another 5 for you.


One of the most interesting files of JMeter is It contains all major properties of JMeter which are important in testing. You can find this file in %JMETER_HOME_DIR/bin directory. There are numerous properties, common and more specific. Many of their values can be helpful during testing, right at runtime. To access property values we can use $__property() function.

Per the JMeter user guide  __property(): The property function returns the value of a JMeter property. If the property value cannot be found, and no default has been supplied, it returns the property name. When supplying a default value, there is no need to provide a function name - the parameter can be set to null, and it will be ignored.

For example:

  • ${__property(user.dir)} - return value of user.dir
  • ${__property(user.dir,UDIR)} - return value of user.dir and save in UDIR
  • ${__property(abcd,ABCD,atod)} - return value of property abcd (or "atod" if not defined) and save in ABCD
  • ${__property(abcd,,atod)} - return value of property abcd (or "atod" if not defined) but don't save it
  • Parameters
  • Attribute
  • Description
  • Required
  • Property Name The property name to be retrieved 'Yes'
  • Variable Name A reference name for reusing the value computed by this function No
  • Default Value The default value for the property 'No'

Let's envision a scenario requiring a decision over whether or not to execute a specific sampler, depending on current log level (see example using $_property(). 
Get the “log_level.jmeter” value; Compare it with pre-defined value in If Controller; Execute (or do not execute) some sampler from the If Controller.

How it can be implemented?

Create a simple test plan that contain one Thread Group. The Thread Group has one If Controller with one HTTP Request Sampler in it. 

In this scenario, it does not matter what URL we put into the HTTP Request, so switch to If Controller to see what happens now.

The sampler here should be executed only in the case of the log_level.jmeter equals “INFO”. In this case, we added the following javascript condition in the “Condition” field: “${__property(log_level.jmeter)}"=="INFO”.  

You can see from the figures above that the log_level.jmeter=INFO. And, as expected, HTTP Request was executed. If switched back to the If Controller, we change “INFO” to “DEBUG” without changing and then re-execute the same testing scenario.

What do ya' get? NOTHING!

As expected, nothing is executed.
Of course, this test plan is a bit extreme as there are very few scenarios where one might run HTTP Requests depending on log_level.jmeter value. But if you understand how it works, you will be able to adapt it to your own testing needs.


Per the JMeter user guide: __counter()
The counter generates a new number each time it is called, starting with 1 and increasing incrementally by one. The counter can be configured to keep each simulated user's values separate, or to use the same counter for all users. If each user's values have separate incrementations, that is similar to counting the number of iterations through the test plan. A global counter counts how many times that request was run.
The counter uses an integer variable to hold the count, which therefore has a maximum of 2,147,483,647.
The counter function instances are now completely independent. [JMeter 2.1.1 and earlier versions used a fixed thread variable to keep track of the per user count, so multiple counter functions operated on the same value.] The global counter - "FALSE" - is maintained separately by each counter instance.
Multiple __counter function calls in the same iteration won't increase the value further.
If you want to have an incremental count for each sample, use the function in a Pre-Processor such as User Parameters .

  • Parameters
  • Attribute
  • Description
  • Required

Argument #1 - True, if you wish each simulated user’s counter to be kept independent and separate from the other users. FALSE for a global counter. 

Yes, yes a thousand times yes!

Argument #2 - A reference name for reusing the value created by this function. Stored values are of the form ${refName}. This allows you to keep one counter and refer to its value in multiple places. [For JMeter 2.1.1 and earlier this parameter was required.] 

No way, no how. Nope, Nada.


But what about using  the counter? How can it be applied to testing scenario? 

Well, there are different ways to use it. As always, create a test scenario that tries to login to an application with invalid credentials. In this case, there is no need to use CSV Data. Set Config element.  Just use a fake pair ofr “user”-“password” with a unique number each time.

How we should fill HTTP Request field in this scenario?

Create a new test plan with one Thread Group having one HTTP Request in it. 

We've added four parameters to the table (“cookielength” is hidden). Two of them, “cookielength” and “passwrd” have fixed values, “360” and “on” respectively.  And another two, “user” and “password” are concatenated from a word and unique number.  As you can see, the unique number is generated with function __counter() with parameter FALSE. Set 20 users in the Thread Group, start the test and switch to View Results Tree for results.

You see that ${__counter(FALSE)} was replaced by  generated values. Used parameter “FALSE” means that counter will have only one instance for all users. That means that number will increase by one from user to user.  If it was set to TRUE, then the counter will generate the same number “1” for all users in the Thread Group.  Notice, that despite the fact that I’ve called __counter() twice per one request, for user and password, counter has returned the same value for both parameters; __Random()&__threadNum().


The random function returns a random number that lies between the given minimum and maximum values.

  • Parameters
  • Attribute Description Required
  • Minimum value A number Yes
  • Maximum value A bigger number Yes
  • Variable Name A reference name for reusing the value computed by this function. No


The thread number function simply returns the number of the thread currently being executed. These numbers are independent of ThreadGroup, meaning thread #1 in one threadgroup is indistinguishable from thread #1 in another threadgroup, from the point of view of this function.
There are no arguments for this function.


The javaScript function executes a piece of JavaScript (not Java!) code and returns its value.

JMeter uses the Mozilla Rhino implementation of JavaScript,  for details of language see Mozilla Rhino Overview. In this particular scenario, we use this function for two goals:

  1. Calculating different expressions;
  • Getting access to JMeter java classes for data, that cannot be accessed via standard GUI element. 
  • Start by calculating and using the same testing scenario as at the beginning of article. Simply modify the HTTP Request for use with __javascript(). 

As you remember, ${__counter (FALSE)} generates a unique value from thread to thread. But inside of one thread this value remains the same. We can fix this issue with using  __javascript(). Multiply the password value by 2 and add 5 more to the user value.  Results are in....

As expected, the password and user received different values that were calculated from 1.


Want to know more about JMeter Functions? Read more in Part 3.

Have more questions? Submit a request


Please sign in to leave a comment.