Home / Docs / Articles / Distributed Load Testing

LPS Distributed Load Testing

The Distributed Version of the LPS Tool supports distributed load testing using a master-slave architecture. This feature enables scaling across multiple nodes, where a master node coordinates the test and workers execute it.

How It Works

The architecture follows a master-slave model, where:

  • Master Node: Aggregates metrics, maintains the global state, and hosts the dashboard.
  • Worker Nodes: Receive test commands locally and wait until the master node is in a Ready or Running state before executing tests.

All communication between master and workers is done over gRPC.

Important: The test command must be executed on each worker node; the master does not launch the worker processes. If the master is not yet ready or running when a worker starts, the worker registers as an observer and waits for the master to trigger the test once it is ready.

If the GRPC port is not open on the master/local node the connecting party will timeout after around 21 or 42 seconds due to TCP handshake failure.

Cluster Configuration

To enable distributed mode, configure the following section in config/lpsSettings.json:

"Cluster": {
  "MasterNodeIP": "192.168.27.196",
  "MasterNodeIsWorker": true,
  "GRPCPort": 8999,
  "ExpectedNumberOfWorkers": 2
}

Settings Description

  • MasterNodeIP: IP address of the master node. Workers use this to send their metrics and status updates.
  • MasterNodeIsWorker: If true, the master node will run test iterations in addition to orchestrating them. The default is true. Set it to false to make the master an orchestrator only.
  • GRPCPort: Port used for gRPC communication. Default is 5001.
  • ExpectedNumberOfWorkers: Minimum number of workers that must register before a master-only node continues orchestration. At least one worker is always required. This setting is ignored when MasterNodeIsWorker is true. It does not define how many workers must complete the test; the master waits for all registered active workers, including workers beyond this count, before exiting.

Running the Master Without Executing the Plan

There are two ways to make the master coordinate the test without executing any test iterations or sending traffic to the target application.

In both approaches, the master prepares the plan, hosts the dashboard, and collects metrics from the workers. Run the test command separately on every worker node.

Use the master Command

Run the following command on the configured master node:

lps master plan.yaml

The master command always runs the node as a dedicated master, regardless of the MasterNodeIsWorker setting. It waits for at least ExpectedNumberOfWorkers to register and then remains active until all registered active workers finish, including workers beyond that count, or until the command is stopped with Ctrl+C or Escape.

On every worker node, run:

lps run plan.yaml

Set MasterNodeIsWorker to false

The same master-only behavior can be applied to the regular run command by setting MasterNodeIsWorker to false in config/lpsSettings.json:

"LPSAppSettings": {
    "Cluster": {
        "MasterNodeIP": "192.168.27.196",
        "MasterNodeIsWorker": false,
        "GRPCPort": 8999,
        "ExpectedNumberOfWorkers": 2
    }
}

You can also update this setting with the cluster command:

lps cluster -miw false

After setting it to false, running the following command on the master prepares and coordinates the plan but does not execute its test iterations:

lps run plan.yaml

Run the same lps run plan.yaml command on every worker. The workers execute the plan and report their metrics to the master.

Notes

  • The dashboard is hosted on the master node, which displays test metrics aggregated from all workers.
  • Workers will not start the test unless the master node is in a Ready or Running state.
  • gRPC ports must be open and accessible between all participating nodes.
  • Test execution must be triggered individually on each node.

Example

Configure the lps cluster:

"Cluster": {
  "MasterNodeIP": "192.168.27.196",
  "MasterNodeIsWorker": true,
  "GRPCPort": 8999,
  "ExpectedNumberOfWorkers": 2
}

CLI Example

Configure a master node with 3 workers:

lps cluster -mip 192.168.1.100 -gp 8999 -ew 3

Configure master node that also acts as a worker:

lps cluster -mip 192.168.1.100 -gp 8999 -ew 2 -miw

Configure with custom gRPC port:

lps cluster -mip 10.0.0.50 -gp 5001 -ew 5

Notes

  • The cluster command configures the Cluster section in the config/lpsSettings.json file.
  • After configuration, run your test on the master node and each worker node using the same test plan.
  • Workers will automatically connect to the master and wait for the test to start.
  • The master node aggregates metrics from all workers and displays them on the dashboard.
  • Ensure the gRPC port is open and accessible between all nodes in the cluster.

Run your test using the CLI command, for example:

lps --url "https://www.example.com" --requestcount 700

The command must be executed on every node.