JMeter Non-GUI Mode: Useful Tips

It's important to understand the JMeter non-GUI mode. In this blog, we'll share tips to help you get started.

Why Use JMeter Non-GUI Mode?

One of the first things that you learn about JMeter is that you shouldn’t use GUI mode to execute the load tests. You should use the non-GUI mode.

The reason is that the JMeter GUI is not designed to execute high loads, and consumes lots of resources that could overload the server, which would give you incorrect information about your test results. Additionally, the more resource consumption the server has, the less load you will be able to generate in your tests.

Therefore, knowing how to run JMeter non-GUI tests in an effective way is very important to ensure proper performance testing.

We already have some posts on our blog that show JMeter basics or the different ways to run tests in non-GUI mode so we won’t go into details here. However, we will provide some useful tips about how to transfer from GUI to non-GUI mode and run successful non-GUI performance tests. 

4 Useful JMeter Non-GUI Mode Tips

JMeter GUI mode is used for recording, scripting and debugging so it’s almost mandatory to use it before the execution stage. You also won’t run into any problems if you run such a JMeter testing script in non-GUI mode. Let’s see which aspects we need to consider to improve the test execution performance and to make your work more seamless:

1. Remove JMeter Listeners

It’s a good practice to use as few listeners as possible, especially avoiding the ones that show real-time results, like “View Results Tree”. 

By using the -l flag in the command when executing from command line, a top level listener will be created for the test run so you can delete or disable all the listeners from your test plan. When adding this flag, you need to specify the name of the jtl file to log sample results to.

jmeter -n -t my_test.jmx -l log.jtl

2. Use Functions in Variables 

When running non-GUI tests, you may need to change script variables each time you start a test. For example, the name of the log in the Simple Data Writer if you need to get a different log from each execution.

This is annoying, since you would have to open the script on the GUI, edit the parameter, and save the script, all before running the test through the command line. 

Therefore, it’s a good idea to use functions like _time or __Random in the variable names to get a different name on each run without editing the script manually.

Functions are special commands that allow the user to define variables to be replaced with static values or compute new values at run-time. You can use functions in any field of any test component, as long as it matches the field format (you can’t put a random string in a field which expects a number for example). Here you can find the list of all JMeter functions and their usage. 

3. Override or Set Properties Through Command Line

If you are following a correct performance testing methodology, you will probably need to rerun the same test with different settings. For example, you might change the number of threads or iterations, ramp-up time, or simply change a hostname to run the test in another environment. 

One way to do this is by parameterizing those fields in the script using variables, and changing them from the GUI before each test run (like in the previous section) but again, it becomes annoying if you have to run various tests in non-GUI mode.

The solution to this is to define the variables in terms of properties. For example, if you want to change the value of the “Number of Threads” field to 15 in a Thread Group, you should follow the next steps:

1. Set the “Number of Threads” field with the value ${__P(threads1,1))} as is shown in the image below. This defines the property threads1, with a default value of 1.

2. When running the test through command line, add the flag -Jthreads1=15 which sets the property with the value defined: 

jmeter … -Jthreads1=15

The -J flag defines a local JMeter property, but it also could be defined properties to be sent to all JMeter servers in remote-testing using -G flag, or Java system properties with -D flag like in all Java programs.

If there are many properties that need to be set at the same time, you could do it by setting a property file and using the -q flag in the command line with the file route.

You can find a complete list of all JMeter flags here.

4. Monitoring

The main disadvantage of running in non-GUI mode is that you can’t see the real-time results on the listeners. However, there are some other options that are explained on this post, or in this other, that enables the tester to see live results during the executions.

The first post explains how to understand the information given by JMeter while running in non-GUI mode, which is not as much information as shown in the listeners but is useful in order to get a basic idea of the test results. Then it shows the advantages, in terms of monitoring, of running the tests with Taurus or, even better, with BlazeMeter. 

The second post explains how to configure your tests to see live results using Grafana and InfuxDB. Grafana is a tool used for time series analytics, which enables the user to create real-time graphs based on time series data, whereas InfluxDB is a time series database which is used as a temporary metrics storage.

Get Started With JMeter Non-GUI Mode

It’s always recommended to run JMeter non-GUI tests instead of GUI tests as you will avoid many performance related problems on JMeter. 

Non-GUI mode is very powerful, almost every feature that could be used from JMeter GUI could be also used either through command line or the properties files. 

Here we have reviewed some suggestions to run non-GUI tests in a better way, but there are many others (like the remaining flags usage) that could be reviewed in JMeter documentation or in other posts of this blog.

START TESTING NOW