How to Get Started With JMeter: Part 2 — Building Scripts and Running JMeter

DZone 's Guide to

How to Get Started With JMeter: Part 2 — Building Scripts and Running JMeter

This tutorial, part two in the series, walks you through building scripts to automate processes within and running JMeter.

· Java Zone ·
Free Resource

MFor those of you just getting to grips with JMeter, we’ve put together a three part ‘how to’ series on how to use this powerful tool. (Note: if you’re already a JMeter pro, you might want to take a look at this webcast on creating advanced load testing scenarios)

This week, we’ll focus on building scripts, running tests in non-GUI mode, logging and error messages, debugging, configuring JMeter, parameterization, and correlations.

Click here for our previous post on installation & test plans.

How to Build a Script

Instead of manually building scripts, the JMeter Proxy enables you to record actions a user would take in your application. You can replay these actions at scale for your performance tests. For example, on a retail site, you can record the actions of a user searching for an item, adding it to the cart, and going through the checkout process. Then, you can test it at scale.

Click here for information on BlazeMeter recording abilities and here to learn about automatic correlation through the SmartJMX mode.

Configuring JMeter’s recording processes requires only three steps:

1. Set up a Recording Controller in a New Thread Group

• Go to the test plan

• Select Add > Threads (Users) > Thread Group

• Select Add > Logic Controller > Recording Controller

This creates a place to capture the recorded interactions.

2. Set up HTTP(S) Test Script Recorder Proxy in the Workbench

• Use the Recording template at: File > Templates > Recording > Create.

To group samplers and to represent grouping in recording (without images):

• If the option “Do not group samplers” is selected — samplers will be stored in a serial manner, without grouping

• If the option “Add separators between groups” is selected - the controller named “-----” will be added as a separation between groups

• If the option “Put each group in a new controller” is selected—a new Simple Controller will be created for each group and all samplers for that group will be stored

• If the option “Store 1st sampler of each group only” is selected—the first request in each group will be recorded, and the “Follow Redirects” and “Retrieve All Embedded Resources” flags will be turned on in those samplers.

3. Configure Your Browser to Send Traffic Through the Proxy

We recommend you use Firefox because it has a standalone proxy configuration option.

• Type “about: preferences” in the address bar to open the control panel.

• Click Advanced in the sidebar and select the Network tab.

• Click the Settings button next to “Configure how Firefox connects to the Internet.” This will open the proxy controls.

• Go back to JMeter and take note of the port setting in the HTTP(S) Test Script Recorder.

• Go back to Firefox and add localhost and that same port number in the Manual Proxy Configuration

Configuring browser to sent traffic through proxy

• Tick “Use this proxy server for all protocols”—it will allow you to record HTTPS traffic as well.

• If you run JMeter and Firefox on the same machine make sure that there is nothing like “localhost” or “” in “No Proxy for” input field.

• Click OK.

• Go back to JMeter, go to the HTTP(S) Test Script Recorder in your Test Plan tree and click the Start button (go ahead and accept JMeter’s temporary security certificate).

Congratulations! You’ve made it to recording mode.

Now all you need to do is act like a user: Browse the site that you want to test, taking all the actions that a user would take. (e.g. Homepage > Pricing > Checkout).

When you’re done, click Stop in the HTTP(S) Test Script Recorder and save by clicking File > Save Test Plan and giving it a name.

Your test script is saved in the Recording Controller.

How to Run JMeter

Running Load Tests in Non-GUI Mode

After building your test, we recommend you run it in GUI mode with a single or low thread count and listeners added and enabled, to make sure everything is operating properly.

After ensuring everything is good to go, run the test from the non-GUI command line mode with listeners disabled or removed. Here’s how:

Option A: Running from a single machine

jmeter -n -t /path/to/test_script.jmx -l /path/to/test_results.jtl is the format to use in the non-GUI command line (and not in the GUI command line)

Tip: Make sure you disable all listeners when running the tests, as many of them use up a lot of memory. You can open the test_results.jtl file with the listener of your choice after the test ends.

Option B: Running from distributed mode

You can run the test via LAN, but this option is limited by the number of physical or virtual machines on your intranet. For this reason, many users opt for the unlimited scalability of cloud-based distributed testing.

Click here to learn more about testing by LAN.

Cloud-based tests provide you with unlimited scalability, which enables you to run hundreds of load and performance tests in parallel, and at a massive scale, from geographically distributed users. Cloud-testing platforms and companies like BlazeMeter enable full integration with this open source tool. Find out more here.

To make sure the systems running the JMeter server are working, open up JMeter.log in notepad. This is what you should see: Jmeter.engine.RemoteJMeterEngineImpl:Starting backing engine

Logging and Error Messages

The JMeter log file can show you troubleshooting information and can be very useful when determining the cause of an error.

To view the log file, go to Options > Log Viewer at the bottom pane on the main JMeter window.

A Typical JMeter Log File:

Typical JMeter Log File

Errors in the JMeter test itself are shown in the JTL log file. For a more user-friendly experience, view the results in the Listener or upload your script to BlazeMeter.

We recommend you set the actions you want JMeter to take if there’s an error. Go to your thread group, and you’ll see an option called “Actions to be taken after a Sampler Error”. Here you can choose to continue with the test, start the next thread loop, stop the thread, stop the test, or stop the test now.


Debugging is probably one of the most important software development practices. If software doesn’t work immediately upon coding, you need to detect bugs and fix them. Here are a few useful JMeter debugging methods:

Real Time Sampler/Expression Debugging

• Test your expression in the RegExp Tester, in the View Results Tree Listener.

• Be aware: Sometimes a test will run well with the RegExp Tester but won’t work when you run the actual test. This is usually due to dynamic content.

View Results Tree Listener

In such cases, it’s easy to find the problem with the Debug Sampler.

• Add the Debug Sampler before View Results Tree and run the test.

• After the test is completed, open up View Results Tree and select Debug Sampler.

Debug Sampler

Debugging JMeter Elements

You can debug all the items in the test tree by printing the debug log. Here’s how:

1. Uncomment jmeter.loggerpanel.display=true in the jmeter.properties file. This change will open a log viewer every time JMeter is started.

2. In the test tree, select any item that you want to see the debug information for.

3. Click the Help menu and then Enable debug. Run the test to see the debug information.

4. Create a simple test with "HTTP Request" and add “HTTP Cache Manager." Select HTTP Cache Manager click Help > Enable debug. Click Options > Log Viewer to see the log message. Now change the loop count to three and run a test.

HTTP Cache Manager Debug Log

Now you are able to see the debug log of the HTTP Cache Manager in the Log Viewer. To disable printing the debug information, select HTTP Cache Manager and click Help > Disable debug.

Configuring JMeter

You can modify your JMeter properties at user.properties in the /bin directory.

Or you can create your own copy of jmeter.properties and then specify it in the command line.


We highly recommend that your load-testing tool can read dynamic data from external sources. So, if you’re testing the system with a large number of users, you need to make sure that JMeter can handle different types of external data inputs and pass the extracted data to the virtual users’ threads.

Instead of hard-coding certain parameters in the test plan, you can make your JMeter test-data-driven by populating the properties and variables from various sources, including:

• The command-line arguments or properties’ files (e.g. you set the application under test host as “jmeter -Jhost=www.example.com” and access it as “${__P(host,)}” in the HTTP Request samplers) .

• The CSV files via the CSV Data Set Config test element of the CSVRead() function

• Arbitrary file types via the FileToString() or StringFromFile() functions

• Databases via JDBC test elements


Dynamic data like those mentioned above (and more) often cause problems in your script—even if your app appears to be functioning properly.

With JMeter, there are three steps you need to take for each value you need to parameterize:

1. Identify the Value. With every request you capture in a JMeter recording, the request parameters are presented clearly in a text box—and they are often labeled something like “authenticity_token” or their value is a long string of random alphanumeric characters, like “33aKfmjPhNmzVBFfxKEx6cmB9C5sjSRAd9VJEaJpba8.”

2. Find Out Which Requests Issue the Value. For example, an authentication token is probably issued in the response to the login request. However, it’s not always the immediately preceding request that issues the value. In such cases, take a look at JMeter’s Results Tree to inspect the responses.

Authentication Token

3. Use a Regular Expression Extractor with a pattern that matches the expected content. Taking the example above, this might appear in the text as: , in which case one regex would be <input name="authenticity_token" type="hidden" value="(.+?")/>. The parentheses tell JMeter to retain the value found inside them, and then places that value into the Reference Name you supplied for the extractor, which we may call something like “authenticity_token.”

Regular Expression Extractor

The JMeter variable format would then be ${authenticity_token}, so you finally go and replace the original captured value wherever it appears in subsequent requests with the variable.

Replace Original Captured Value

Now you’re good to go!

Check back next week for information on reports and performance metrics and best practices

Need more JMeter training? Check out our free online course.


Published at DZone with permission of Noga Cohen , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}