Performance Testing: Samples Isolation

This article is intended to explain the important use case of sharing data across the ThreadGroups in JMeter where most developers/test engineers face these challenges. Let's start with the example use case below:

1. Create JDBC Requests in a ThreadGroup.
2. Retrieve the Results.
3. Share the Results to Another Thread Group
4. Use the Results to Send the HTTP Calls.

As part of this material:

• We will identify what's wrong with running the entire test in the same Thread Group.
• Excluding the latency of JDBC calls to measure the performance of the API.

Let's get into the action:

Open JMeter by going to it’s bin directory and running ./jmeter (Unix).

Download this SQL Connector, if you are doing it for first time, and point to this when JMeter asked: http://central.maven.org/maven2/mysql/mysql-connector-java/5.1.6/mysql-connector-java-5.1.6.jar

Next, name your TestPlan and save it. (ExampleTestPlan)

Then, create aThreadGroup:

Then, give it a name: (DBThreadGroup) — Observe the configurations of Number of Threads, Loop Count.

Create a JDBC Connection Configuration by right-clicking to the TestPlan:

Enter the Configurations: Variable Name for Created Pool Name(gopiCustomConnectionPool), URL(jdbc:mysql://localhost:3306/test), DriverClass, Username, Password.

Move the JDBC Connection Configuration up.

Add the JDBC Request:

Next, choose your database table. Then, add your variable name and result variable name. Result variable will contain the entire result-set, where as variable name (empId) will be used to append with a number to represent each record. For example, “empId_1”,“empId_2”…etc. (That's the inbuilt behavior of JMeter, and this is an important understanding).

Add a Debug Sampler. This will be helpful to see the results of JDBC Request made at 7, while running the test.

You can set the all properties to true if you would like to see all of them during run time.

To export all variables in this thread group to the other, start adding a for-each controller.

Now, all JDBC results that were captured into the variables can now be exported as properties to access in the other Thread Groups. So, there should be a spark in your brain; there are two aspects that you need to understand:

• →12.1 Variables : Useful with in the context of ThreadGroup.
• →12.2 Properties: Can be used across the ThreadGroups.

It is important to separate these ThreadGroups, because we want to run only the HTTP Requests in another and are not interested in taking the count of JDBC requests in our performance test.

Give the prefix of the variable and resulting pointer of the for loop.

Then, add an index mover of the for loop using the Counter Config Element:

Give the Staring Value, Incremental Value, and the Exported Variable Name to use in this ThreadGroup. Tick Mark is needed only when you want to run this counter across multiple Threads. Since this ThreadGroup is configured with defaults, it doesn’t matter your selection. Number of Threads: 1, Loop: 1, Ramp-up time: 1 Second

Add a JSR223 Sampler to run your Java code:

Put every variable available into the Properties. Also, with the below change, we have now completed the DB Thread Group.

It's now time to create a new ThreadGroup. Create a new one with the below Threads where we can really stress the system with our tests. API Calls are going to be inside this ThreadGroup. Now, you should be able to understand why we separated out the ThreadGroups.

Add a new Debug Sampler to see the flowing variables:

Next, add a JSR223 Sampler to run the Java code that can convert the Properties to Variables back.

Enumeration e = props.propertyNames();
while (e.hasMoreElements()) {  
  String propertyName = e.nextElement().toString();  
  if (propertyName.startsWith("empId_")) {      
    vars.put(propertyName, props.getProperty(propertyName));  
  }
}

Add a for controller and counter again to go through each variable to kickoff the HTTP Request.

It's time to add a HTTP Request:

Configure the HTTP Request as below:

${__V(empId_${index})}

Since nested variables are not allowed, we need use the __V function next to them. So, the For and Counter together will keep forming “empId_1”, “ empId_2”…etc., which will be replaced with the actual employeeId supplied all the way from JDBC Fetch.

Add a View Results Tree inside the ForEach to see each request status after the test ran. Also, add the Summary Report under the ThreadGroup to see over all the Thread Group Summary.

Now, running the test can result in the example summary below:

You can also see the Call Failures and the Status codes under the View Results Tree.

Make sure your test API Call is up and running before kicking off the test.

Happy testing!