Eric Dapp is an Adoption Engineer at BlazeMeter and an instructor at the BlazeMeter University. He's got over 3 years experience in performance testing, helping teams realize their performance and automated testing goals.

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)
Jul 21 2020

Using Redis Dataset JMeter Plugin to Control your Test Data on the Fly

Imagine that you’ve got an application that you want to performance test, and that application requires data to be consumed while testing. Chances are, if you’ve had this need (and you’re familiar with JMeter) then you’ve used the CSV Data Set config. The CSV Data Set Config has some great features, letting you control most aspects of how data will be consumed for your test.


One major shortcoming of the CSV Data Set Config, however, is that once the test has started, you need to have access to the file that JMeter is using if you want to update the data being used. Otherwise you’re locked in to the data that can be used for the test. For tests that you’re running on your local computer, this shouldn’t be an issue, you just save the CSV file with new data (or remove data you don’t want), and JMeter will reflect that change as long as it still has that file open.


Where this presents an issue is when you’re scaling your tests with BlazeMeter. Using a CSV file for data in this scenario will mean that each instance of your test running in the cloud will have it’s own copy of the data, making it problematic to make changes to the data. What we want is a flow more like Virtual Table Server (VTS), where we’d use a centrally located data source. This is the issue that we’re going to address with the Redis Dataset Plugin.


Note that in order to follow along with this scenario you’ll need to have a BlazeMeter account, a Redis server running somewhere that BlazeMeter’s cloud engines can reach, and have the Redis Data Set plugin installed in JMeter (you can get it from the Plugins Manager!).


  1. Setting up our Redis List


I’ve got my Redis server hosted in the cloud, but you can install it on your local computer as well. The first thing that we’re going to do is add some values to a Redis List using redis-cli command for LPUSH or RPUSH (depending on if you want it added to the start or ending of the list), like this:


LPUSH list-key value1 value2 value3


One nice thing about Redis is that if the key for the list doesn’t exist, it will be created with this command. Specifically, ahead of writing this article, I added three “lines” to a list called “jmeter” where each entry represents two variables that can be used by our JMeter test separated by a comma, created like this:


LPUSH jmeter value11,value12 value21,value22 value31,value32


Now, I’m going to SSH (Secure Shell) into my redis server and start working with the list. We can check the values that are in an existing List with the LRANGE command. Here we’re using


LRANGE jmeter 0 -1


to specify that we want to see all the entries in the list, from index 0 (first) to -1 (last).



2. Configuring JMeter


So we can see that all the elements have been added, and that each element is in the format we want. Next we’re going to configure JMeter to utilize this data set.


Startup JMeter, add a Thread Group, and add the Redis Data Set Configuration Element. When looking at the Redis Data Set configuration, you’ll see a number of fields we’ll need to specify for this to work. First check out the connection configuration:



We’ll need to specify the IP address (or hostname) of the server where Redis is hosted, the port that Redis is using, and the Password for authentication with Redis. Note that if you’re running Redis locally, using localhost (or won’t work when we bring this test to BlazeMeter, in this case you’ll need the public IP address where your Redis server can be accessed remotely.


The other important information is how the data is going to be consumed.



We’ll need to specify the key that we used in Redis to identify our List and use the Variable Names field to determine how we’ll refer to our variable in our script (note that these should be comma separated). Since we separated our values with commas on our Redis server, we can leave the Delimiter with its default value. We’ll also need to select the Data Source Type.


At this point it’s worth noting that we could have used either a Redis Set or a Redis List. I’ve opted to use a List since it will work for us most like using the CSV Data Set Config would have. The difference between using a Set and a List is that a List has a specific order and can have duplicate values, whereas a Set will be retrieved in random order, and duplicate values added to a Set will be ignored.


Next I’m going to add a Dummy Sampler to my test to illustrate this use case without having to create any real load.



So that we can see when a change happens, I’m setting the Name of my Dummy Sampler to “Dummy: ${first} and ${second}” this way, the labels will tell us what value is being read from the Redis server. After we test this locally to make sure that our test can connect to Redis, let’s upload this test to BlazeMeter.


3. Scaling our Test on BlazeMeter



Note that unlike using a CSV Data Set Config, we don’t need to include any other files, as we’ll be getting our data remotely.


When we run this test, we see that the labels that show up are being populated with data from our Redis server.



Let’s go and add a value to our Redis LIST with


RPUSH jmeter value41,value42



Give it a few minutes and as your test runs, JMeter will reach out to your Redis Server for the next set of values it should use. When the report data updates in BlazeMeter, we’ll see a new label show up.



Working backwards, to see when this data was introduced in the test, we can isolate it, and see that the label “Dummy: value41 and value42” starts showing up part way through the test, at a time corresponding to the change in the Redis server. It doesn’t matter if the test is using one engine in the cloud or scaled across hundreds, we’ve built it in a way to update all the data used in all the tests (but make sure that your Redis Server can handle the load!).



Have you ever been running a test and thought to yourself: “well, I wish I’d added more data to this before I started” only to have to abandon a test run and start over to make the test you really want? Have you ever been running a “log replay” performance test where your test is reading URLs from a CSV, and suddenly want all your virtual users to focus on hitting one URL? Have you ever taken the time to set up a big test event, only to realize once it’s running that one of your 1000 entries of data is wrong and will always result in an error?


There are any number of ways that having access to a centrally located adjustable data source can be used when testing, these are just a few to think about.


You can check out other JMeter Plugins developed by the BlazeMeter labs team here.


Ready to get started with running your tests? Just click here to start testing, or put your URL in the box below.

arrowPlease enter a URL with http(s)

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