JMeter in Action.

Gopi Krishna Kancharla
Aug 12 · 6 min read

Performance Testing — DB & API Samples Isolation.

🍈 This article is intended to explain the important use-case of Sharing Data Across the ThreadGroups in JMeter, Where most of the Developers/TestEngineers face the challenges. Starting with the below example use-case.

  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 whats wrong running the entire test in the same thread group.

→ Excluding the latency of JDBC calls from to measure the performance of API.

Lets get into 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:

  1. Name Your TestPlan and Save it. (ExampleTestPlan)

2. Create a ThreadGroup

3. Give a Name: (DBThreadGroup) — Observe the configurations Number of Threads, Loop Count.

4. Create a JDBC Connection Configuration on right clicking to the TestPlan

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

6. Move the JDBC Connection Configuration up.

7. Add JDBC Request

8. Choose your database table. 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. Ex: “empId_1”,“empId_2”…etc. (Thats the inbuilt behavior of JMeter and this is an important understanding required)

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

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

11. To Export all variables in this thread group to other, Start adding a for-each controller.

12. As all the JDBC Results 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 pieces to understand.

12.1 Variables : Useful with in the context of ThreadGroup.

12.2 Properties: Can be used across the ThreadGroups.

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

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

14. Add an index mover of the For Loop using Counter Config Element:

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

16: Add a JSR223 Sampler to run your Java Code:

17: Put every Variable available into the Properties. Also, With the below change, we are now completed the DB Thread Group.

18: Time to create a new Thread Group. Create a new one with the below Threads where we can really stress the system with our tests. API Calls going to be inside this Thread Group. Now, you should be able to understand why we separated out the ThreadGroups.

19: Add a new debug Sampler to see the flowing variables:

20: 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));

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

22. Time to add a HTTP Request:

23. Configure the HTTP Request as below


Since Nested variables are not allowed, we need use the __V function to next 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 Thread Group to see over all the Thread Group Summary.

Now, Running the test, can result the Summary as below: (Example)

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

Thanks. Make your Test API call up and running before kicking off the test.

Find the publication here:

Gopi Krishna Kancharla- Founder of

Think Special

Let Machines Work Smart

Gopi Krishna Kancharla

Written by

Software Engineering Leader @ CapitalOne-Garage

Think Special

Let Machines Work Smart

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade