Effective Strategies for Managing Test Data in High‑Performance Load Testing

Static Data

Static data such as user accounts and passwords are the easiest to provision. For a simple login scenario you can store credentials in a configuration file and load them before each test run. Two common patterns are:

One‑time login: Keep long‑lived credentials in a file and reuse them across the entire test.

Login per iteration: Re‑authenticate each virtual user before executing the test flow, which is necessary when credentials expire after inactivity.

Choosing the first method is preferable when the number of users is large and the login step would otherwise dominate the test duration.

Dynamic Data

Dynamic data falls into two categories: data generated during the test and data fetched from upstream services.

Generated During Test

For example, a follow‑then‑unfollow scenario in a social app can be modeled by first calling the follow API and then the unfollow API, linking the responses so that the unfollow request uses the ID returned by the follow request.

Fetched From Upstream

If you need to test an unfollow API in isolation, you must pre‑populate the user's follow list. One approach is to query the latest follow list via an API before the load test and use that data during execution, taking care to maintain thread safety.

Asynchronous Data

Some workloads require continuously updating data, such as a flash‑sale scenario where 10,000 users compete for limited items. The test can be split into two processes:

Core process: Sends purchase requests using a global variable for product IDs.

Async process: Continuously refreshes the product ID list, possibly adding new items via an “add product” API.

The async process also monitors for out‑of‑stock signals and updates the global variable accordingly, which is typical for long‑running stability tests that need fresh data without a one‑to‑one mapping to the target API.

Distributed Testing

When scaling load generation across multiple nodes, data isolation becomes critical. A common solution is to assign each node a distinct subset of test data, often retrieved from a registration service or a shared message queue. This prevents interference between nodes and mimics real‑world traffic replay scenarios where captured traffic is stored in a data warehouse and replayed per node.

Handling Massive Configuration Files

For gigabyte‑scale traffic recordings, you can either load the entire file into JVM memory (if hardware permits) or use a local queue to stream the file line‑by‑line to worker threads. The latter avoids memory pressure and, based on benchmark results for Java and Go queues, does not become a bottleneck even at 100k QPS.

Tools such as goreplay support direct replay of local traffic files, and the Chronicle queue library offers high‑throughput, low‑latency messaging (e.g., 40 GB of messages at 1.2 M TPS) for extreme performance tests.