One of many useful features of JMeter is that almost all of the stuff that you can select/input in its GUI, you can also alter programmatically during runtime.

Today, I will describe an example of this in context of downloading embedded resources for some of the requests. I will show why I had to go for this feature and how I made it stick.
 

Retail context

Recently, I did a consultancy project that included JMeter script implementation for an online store of a retail business.
My job was to develop the script following a structure of an already existing script made for another customer.

To give you a bit of context of performance testing online stores, one of the most important things there is to make a clear distinction between new users visiting the site for the first time and returning users.

They differ strongly in terms of requests issued to the server (returning users have lots of stuff already cached locally). You need to analyze the numbers from production, get the ratio of new/returning users and simulate the workload accordingly.

 

Here is where the things got nasty for me. The script that I’ve received as a template had separate branches for new/returning users. Which basically means that dozens of requests were doubled in the script.

It looked a bit like this:

 

The only differences between the new/returning user transaction branches were that the new user requests’ had:

  • downloading embedded resources marked for html pages requests,
  • few extra server calls added.

 

That raised a red flag of maintenance NIGHTMARE. Imagine that the application changes and you need to apply the same exact changes to the script in two places. That is a huge waste of time and can lead to additional issues when adding changes with copy-paste.
 

JMeter’s API to the rescue

I immediately had started to search for a possibility letting me to simplify the script’s structure. I had to replace the GUI functionality for downloading the embedded resources (see screenshot below) with its corresponding API calls to enable it for new users.
 

 
Firstly, I checked the JMeter API for HTTP Sampler. I easily found the setConcurrentDwn, setConcurrentPool and setEmbeddedUrlRE methods, but I couldn’t nail the main target of how to mark the “Retrieve All Embedded Resources” checkbox within the code.

Finally, I decided to check the JMeter source code, learning that the method I was looking for is called: setImageParser(boolean)!? Well. Not really a straightforward naming for this method I must say…

 

Calling the APIs in the script – solution

The ultimate goal was to be able to simulate both groups of users utilizing a single transaction branch, without doubling the requests.

I started in the [Thread group] component, deciding in each iteration, whether new or returning user will be simulated. Such information is then stored in [UserSession] JMeter variable, basing on this value a certain code and requests will be executed later on.

 

 

As you can see in the screenshot above I put a [PreProcessor] components under requests that fetch htmls, like 01_01 request above. Inside them, I implemented a simple check whether currently I’m simulating a returning user or new one, setting the options to download embedded resources in the latter case:
 

if (vars.get("UserSession").equals("NewUser")) {
	// Enabling embedded resources download for the new user browsing the page
	sampler.setImageParser(true);
	
        // Set configuration for the embedded resources download:
	// should parallel threads be used when downloading resources
	sampler.setConcurrentDwn(true);
	// number of parallel threads used to download the resources fetched from a variable
	sampler.setConcurrentPool(vars.get("EmbeddedResourcesSizeOfThreadPool"));
	// regular expression for the resources to be downloaded fetched from a variable
	sampler.setEmbeddedUrlRE(vars.get("EmbeddedResourcesFilter")); 
}

 

In the screenshot you can also see an [If] component triggering some additional requests for the new users only. And that’s all.

Thanks to the simple JMeter API solution I was able to greatly simplify the structure of the script. Implementation was quite quick and future maintenance of the script looks definitely less daunting.
 

Take away stuff

Other case when the API comes handy might be when you need to simulate a http request each time having different number of form parameters sent depending on some previous server responses. Then, you just add them dynamically in the request’s [PreProcessor] and you’re good.

I also recall one hardcore example of a script which basically comprised a while loop with a http request inside. All of the content of the request (http method, parameters, path etc.) was fetched each iteration from a csv file and set dynamically in a [PreProcessor].
 

When you face a problem in JMeter script that cannot be implemented using standard components, functions or just looks very messy – don’t panic! Remember that you have JMeter API – it might be your savior.