Payload Files

Payload files are another way to get loader to send varying data to your app. There are two types of payload files: classic and variable.

Classic #

A classic payload file contains a set of keys, and a list of sets of data. Loader takes one set of data on each request and automatically adds the data to the request body or query string, depending on the request method. The file should contain JSON data like this:

{
  "keys": ["username", "password"] ,
  "values": [
    ["steve", "h4x0R"],
    ["joe1", "silly"],
    ["jack", "<3jill"],
    ["jill", "<3jack"]
  ]
}

On each request, loader.io will send a different set of data from your payload file:

request 1: username=steve, password=h4x0R
request 2: username=joe1, password=silly
request 3: username=jack, password=<3jill
request 4: username=jill, password=<3jack

The data is not necessarily in the same order - it does get randomized.

Place your payload data in a file at any publicly-accessible URL (S3, Dropbox, or your own server is fine—somewhere we can get at it), and enter the URL in the "Payload file URL" field, inside the "Parameters" section:

Variable #

The variable payload file is similar, but instead of automatically populating the request body or querystring, the  values are made available as variables, so you can use them in parameters, headers, or even the URL path. The file should look like this:

{
  "version": 1,
  "variables": [{
    "names": ["username", "password"],
    "values": [
      ["steve", "h4x0R"],
      ["joe1", "silly"],
      ["jack", "<3jill"],
      ["jill", "<3jack"]
    ]}
  ]
}

Upload the file to a public URL just like a classic payload file, and paste the URL into the same input in the parameters section. To use the variables, use the same syntax as for  header variables.

The scope of variables defined in these payloads is all requests in the test, so you can define a single file attached to the first request, and use the same variables in subsequent requests.

The screenshot below shows how to create a JSON payload using variables using the variable payload file example above:

Variable Sets #

For simple cases, you only need one set of variables. The "variables" object is an array, and each object in the array is a variable set. The example above defines a single variable set. We guarantee that any variables defined in the same variable set, like "username" and "password" above, will use values from the same value sub-array.

Defining multiple variable sets lets the values vary independently, so you might have a set of user data and a set of location data, and on each request you want a user to be randomly paired with a latitude/longitude combination. Lets look at a simplified example with some dummy values:

{
  "version": 1,
  "variables": [{
    "names": ["username", "password"],
    "values": [
      ["user-1", "pass-1"],
      ["user-2", "pass-2"],
      ["user-3", "pass-3"],
      ["user-4", "pass-4"],
      ["user-5", "pass-5"],
      ["user-6", "pass-6"],
      ["user-7", "pass-7"],
      ["user-8", "pass-8"],
      ["user-9", "pass-9"],
      ["user-10", "pass-10"],
      ["user-11", "pass-11"],
      ["user-12", "pass-12"],
      ["user-13", "pass-13"],
      ["user-14", "pass-14"],
      ["user-15", "pass-15"]
    ]
  },
  {
    "names": ["lat", "lng"],
    "values": [
      ["lat-1", "lng-1"],
      ["lat-2", "lng-2"],
      ["lat-3", "lng-3"],
      ["lat-4", "lng-4"],
      ["lat-5", "lng-5"]
    ]
  }]
}

Without the randomization step, you would see the following:

request 1: username=user-1, password=pass-1, lat=lat-1, lng=lng-1
request 2: username=user-2, password=pass-2, lat=lat-2, lng=lng-2
request 3: username=user-3, password=pass-3, lat=lat-3, lng=lng-3
request 4: username=user-4, password=pass-4, lat=lat-4, lng=lng-4
request 5: username=user-5, password=pass-5, lat=lat-5, lng=lng-5
request 6: username=user-6, password=pass-6, lat=lat-1, lng=lng-1
request 7: username=user-7, password=pass-7, lat=lat-2, lng=lng-2
request 8: username=user-8, password=pass-8, lat=lat-3, lng=lng-3
... and so on...

As you can see, we iterate over each set of data independently, so once we reach the end of the lat/lng values we go back to the beginning. When you run this test in loader the same thing happens, but the values are sorted into a random order first, so each run will present different combinations of the data.

Payload Splitting / Unique Data #

We split payload data between load generators for all "Clients Per Test" and "Clients Per second" test types, so if you provide a payload file with enough unique values, each request is guaranteed to be unique.

How to know how many values you need to avoid duplicates:

• Clients Per Test: the number of values should match the number of clients for the test. For a "1000 Clients Per Test" test, you would need 1000 values
• Clients Per Second: multiply the number of clients by the duration. For a 60-second "1000 Clients Per Second" test, you need 60 * 1000 = 60,000 values
• Maintain Load: Data is not split up by server

Payload file splitting is enabled for all "Clients per Test" and "Clients per Second" tests.

Maintain load tests generally make a lot more requests than the other test types, and even if we did split the data per server, duplicates would still be likely for most tests. So we don't make any attempt to prevent them.