Federico Toledo is the co-founder and director of the software testing company Abstracta, and holds a PhD in Computer Science from UCLM, Spain. With over 10 years of experience in performance engineering, he's helped many companies to successfully improve their application performance. He is dedicated to testing education, having written one of the first books in Spanish on testing and formed Abstracta Academy. He is also a co-organizer of TestingUY, the biggest testing conference in Latin America.

Learn JMeter in 5 Hours

Start Learning

Run massively scalable performance tests on web, mobile, and APIs

Mar 20 2017

4 Things You Should Never Do with Your JMeter Script

Your JMeter scripts are complete and you’re ready to run them in JMeter or in BlazeMeter. All set, right? Hold on. Before you click ‘start’, here are 4 tips and best practices for things you shouldn’t do with your JMeter script.


Making sure you don’t do these four things will ensure your tests run as smoothly as possible and will save you from the eventual headache of trying to decipher an unreadable script. More importantly, if you don’t do these four things, you’ll be able to have more confidence in the results, without saturating the load generators.


1. Don’t make your script too heavy


Your script should be light. So don’t add an exaggerated amount of validations, logic, response parses, debuggers login information, etc., that will just weigh down the script. Otherwise, you won’t be able to execute much load on a machine without saturating its resources, a situation to avoid in order to obtain trustworthy results.


The same happens when you enable too many listeners because they collect a lot of data and render the information in real time which is very resource consuming. Try to avoid this, and even more so when you plan to use Blazemeter to run your performance tests.


2. Don’t run the script exactly as you recorded it


After recording your script, there is still some work to do before you run it. It’s necessary to correlate variables, parameterize and add elements, to faithfully simulate users.


Here is a short list of general samplers and modifications that you’ll need to consider:

  • Add a Cookie Manager - pay attention whether you need to erase the cookies on each iteration or not (you can set this with a checkbox in the sampler).
  • Add a HTTP Request Default Sampler to define the server, port and protocol in just one place. If you erase this specification from your requests, you will be able to change your test environment easier.
  • Review which Response Assertions you need to add.
  • Parametrize Hosts in the Headers to make your script more flexible and supportable.


There may be other samplers you need to add depending on your scripts, like Cache Manager, counters, regular expressions, Authoritation Managers or CSV Data Set Config (if you need to read a data file). All of these actions will help you to develop your script in a way that simulates real user actions, which is critical for obtaining reasonable results.


3. Don’t include absolute file paths


Always use a relative path that allows you to run the script from other machines without having to modify it, especially when you need to work with data files. It’s not practical to change the path of your files each time you want to change your workspace. By adding relative paths, you are able to save time later on. This is possible because relative file names are resolved in JMeter according to the active test plan’s path. So make sure CSV files are stored in the relative directory JMeter starts from.


Here is an example of an absolute path setting (the incorrect way):


jmeter path setting


And now, here is how to do it the recommended way:


jmeter path setting


In addition, if you are planning to run your test in BlazeMeter, you won’t need to add a path to your file path specifications, but rather only specify the file name. BlazeMeter understands that the data file is in the same directory as your script.


4. Don’t leave URLs that don’t actually matter to you


After recording your script, you might find some URLs in it that were generated by the browser, like Google Analytics, certain plugins, Windows Update, etc. These make your script less readable and heavier (because the script will generate more requests) without adding any value to the test. So verify each request you include in your script and check that the host you are addressing is part of your SUT (system under test). If not, just erase them. Focus only on measuring the performance of servers that you are interested in.


Let’s look at this example of an external URL in a test. Suppose we are testing Abstracta’s servers (this is my company so please do not try this at home!). This means I would be interested in the host, “www.abstracta.us”.


Here’s what it would look like:


jmetetr erase urls from script


But in our just recorded test plan we see this URL belonging to an external server - www.youtube.com:


jmeter erase urls from script


We are not interested in testing Youtube's servers, so we need to erase this request and any others like this one, in order to develop a script that is much more readable.


We’re interested in hearing your tips for writing JMeter scripts! So please share in the comments section below.


Interested in learning more JMeter? Check out this free 5 day online course.


Looking for more advanced JMeter? Check out this free webinar.


Want to try out BlazeMeter? Request a demo or start testing for free by putting your URL in the box at the top of the page, and your test will start in minutes.

Interested in writing for our Blog?Send us a pitch!

Your email is required to complete the test. If you proceed, your test will be aborted.