Data Partition

Data partitioning helps clustered runs split test data without overlap. Use it when each node should work on a different slice of the dataset.

What this page helps you do

What this page helps you do

Data partitioning helps clustered runs split test data without overlap. Use it when each node should work on a different slice of the dataset.

Who this is for

Teams moving from one machine to coordinator-and-agent execution or tighter workload targeting.

Prerequisites

  • A scenario that already works in a single-node run

By the end

A clearer cluster topology and the fields that must line up across nodes.

Use this page when

Use this page when execution topology, partitioning, or targeting changes how the run should be distributed.

Visual guide

Cluster topology diagram showing the coordinator, agents, and merged result.
Cluster settings matter because the coordinator, agents, and merged result all belong to the same workload definition.

Guide

What partition data is for

Partition data prevents every node or scenario copy from sending the same dataset rows. It is the simplest way to avoid duplicate test data, duplicate ids, and duplicate writes during clustered runs.

Where the values come from

LoadStrikeScenarioInitContext.ScenarioPartition exposes Number and Count. Use those values to divide files, database rows, tenant lists, or generated ids across copies or nodes.

What a safe strategy looks like

Treat Number as the current shard index and Count as the total shard count. Keep the partition logic deterministic so reruns and debugging sessions choose the same slice of data for the same partition.

Cluster setup samples

Use these samples to compare the documented cluster settings and helpers before you move the workload onto coordinator and agent nodes.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

Partition Test Data by ScenarioPartition

using LoadStrike;

var allUsers = Enumerable.Range(1, 10000).Select(i => $"user-{i}").ToArray();
var partitions = new ConcurrentDictionary<string, string[]>();

var scenario = LoadStrikeScenario.Create("partitioned-users", context =>
    {
        var shard = partitions[context.ScenarioInfo.InstanceId];
        var userId = shard[context.Random.Next(shard.Length)];
        return Task.FromResult(LoadStrikeResponse.Ok(statusCode: "200", message: userId));
    })
    .WithInit(init =>
    {
        var p = init.ScenarioPartition;
        partitions[init.ScenarioInfo.InstanceId] = allUsers.Where((_, i) => i % p.Count == p.Number).ToArray();
        return Task.CompletedTask;
    })
    .WithLoadSimulations(LoadStrikeSimulation.KeepConstant(4, TimeSpan.FromSeconds(20)));

LoadStrikeRunner.RegisterScenarios(scenario)
    .WithRunnerKey("rkl_your_local_runner_key")
    .Run();

Partition-related fields

initContext.ScenarioPartition.Number

Zero-based shard number for the current scenario instance or node.

initContext.ScenarioPartition.Count

Total shard count available for the scenario run.

Partition formula

A common pattern is rowIndex % Count == Number so every row is assigned to exactly one shard.

Deterministic ids

Append partition number and invocation number to generated ids when uniqueness matters across nodes.

shard(i) => i % partition.Count == partition.Number