Learn how LoadStrike approaches distributed load testing with coordinator and agent roles plus NATS-backed execution.
LoadStrike handles distributed load through coordinator and agent patterns that let the test stay one workload even when execution spans more than one node. The docs also describe NATS-backed distributed execution for teams that need a broader self-hosted load footprint.
That matters when a single host is not enough for the workload, the scenario needs environment-specific placement, or the team wants one transaction-aware runtime across multiple execution nodes.
One node is no longer enough for the workload, but you still need the run to behave like one transaction-aware test instead of a pile of disconnected generators.
Placement, browser capacity, and multi-node coordination change the realism of the run, and those constraints need to stay tied to the same reporting surface.
Spread traffic across nodes while keeping one coordinated report.
Place browser workloads where capacity and dependencies make sense.
Target the right scenarios to the right agents without losing the workload definition.
Teams that need multi-node execution for scale, placement, or operational realism while keeping one transaction-aware report surface.
Single-host runs can stop being representative when the workload needs more traffic sources, more browser capacity, or explicit coordination between roles. Endpoint-only tools also tend to make multi-node orchestration a separate concern from the transaction model itself.
LoadStrike publishes cluster overview, coordinator-and-agent, NATS-backed distributed execution, and targeting docs so the cluster shape, scenario selection, and self-hosted rollout controls stay visible in the public documentation.
These pages cover the public clustered-execution story in LoadStrike.
Start with the high-level cluster model.
See the core coordinator/agent pattern.
Target the right scenarios to the right roles.
Review NATS as part of the public distributed story.
Yes. The docs include cluster overview and coordinator-and-agent pages that explain how the distributed execution model is framed on the site today.
Yes. The documentation describes NATS-backed distributed execution and also includes a NATS endpoint guide for teams already working with NATS in the workload itself.
Open the cluster overview, coordinator-and-agent, and node-targeting docs first, then connect that reading back to the workload pages for microservices, event-driven, or browser-aware testing.
Start with the implementation details that match this page.
Cluster mode lets one LoadStrike run spread across multiple nodes. Use it when a single machine is not enough or when topology matters.
Learn how coordinator and agent nodes split, execute, and merge one clustered LoadStrike run.
Node targeting decides which scenarios stay on the coordinator and which are pushed to agents in clustered runs.
Use these comparison pages if you still need a tool-level decision.
Compare LoadStrike and Apache JMeter across scenario design, protocol coverage, downstream correlation, browser workflows, reporting, and self-hosted operations.
Compare LoadStrike and Gatling across scenario discipline, request modeling, downstream visibility, transport breadth, reporting depth, and self-hosted operations.
Connect the run output to the observability backend your team already uses.
See how the LoadStrike TimescaleDB sink fits into transaction-aware reporting workflows and public Grafana starter assets.
See how the LoadStrike Grafana Loki sink fits into transaction-aware reporting and public Grafana starter assets.
Keep moving with the most relevant follow-up pages.
See how the deployment model fits multi-node programs.
Connect distributed execution back to service-heavy workloads.
Review the methodology checklist for topology, workload shape, and artifacts.
Open the cluster docs first, then confirm which scenarios belong on which nodes and whether the plan covers the execution pattern you need.
