March 12, 2013

JMeter differentiates between variables and properties. This difference often leads to confusions. Within your testplan you probably often define variables. Often variables are defined within the testplan.



As you can see HOST and PORT are defined and can be used throughout the testplan using ANT style references like ${HOST} and ${PORT}. Thus you can create tests that are independent of the host and the port, but you have to change the testplan. Often you want to define the host and port simply when you execute your loadtest.

Now comes the pitfall: Variables cannot be set via the command line! Cannot and – as far as I get it – never will. But there is an alternative: properties.

Properties can be defined from the command line, and can be read from the testplan using an – in my opinion – quite ugly syntax: ${__P([property],[defaultvalue])}. Properties are passed using the -J option to the jmeter start. So executing

sets the properties HOST and PORT. But there is a drawback with properties. Properties cannot be set easily within JMeter itself. You have to resort to beanshell expressions to change them.

Suggestions on usage:

Only use variables within your testplan. Even though you now realize that there is a difference between properties and variables, that guy that will maintain your loadtest when you are on holiday will most probably not and he will be confused seeing mixed references like ${HOST} and ${__P([PORT],[80])} within the testplan.

Thus what I always do is to allow variables to be initialized with properties, but only use variables internally. To do that I define my variables on the testplan and allow there variables to be initialized with a property, but always use the variable within the testplan:



Properties and variables can lead to some confusion when using JMeter. In my opinion it is meaningful to use only variables within the testplan itself to not further confuse maintainers. So what do you think? How do you tackle the property/variable issue in JMeter?


Leave a Comment


  1. A

    How to pass Start time for thread group from command line

  2. S

    Arjun, I did not test this, but I think you can use the same approach here and pass the parameter on the command line and parameterize the time when the test should be started.

  3. great idea. i write my tests in the GUI but run them from the commandline, so i always need both.

    also: this allows you to set the default once (in the user defined variables), and only change it there even though it might be referenced in many threads.

  4. E

    Hello Stefan,
    When you saying : “Properties cannot be set easily within JMeter itself. You have to resort to beanshell expressions to change them.” what do you mean by that. How we have to extract them in bean shell. I am passing properties from command line to Jmeter, and I am trying to use it late in bean shell post-processor, but I am not sure what syntax to use in beanshell.
    I tried ${destinationFolder} and String destinationFolder = props.get(“destinationFolder”); nothing seems to work. Any help would be appreciated, thank you in advance. Elena

  5. M

    Stefan, thanks for this post. The no #1 thing I took away was how to recognise the differences between properties vs. parameters.

    I’ve developed some REST API tests in JMeter and then plugged them into Jenkins. as the tests need different values per environment I decided to have a property file per environment. I have added the environment name as a build parameter and as also a property of the test.

    The test than ‘reads’ the environment name from the property and uses that dynamic value to define the name of the property file. From that every dynamic value from the file becomes the ‘right’ value for that test x environment.

    e.g. number of threads; number of users uses larger value for pre-prod vs sit or uat say

    Many thanks for the lightbulb moment

  6. R

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.