Introduction to Rounds

Key Attributes of a Round

• Name: Identifier for the round.
• Startup Delay: Time to wait before the round starts.
• Number of Clients: Specifies the number of simulated users for the test.
• Arrival Delay: Time in milliseconds to wait before each new client arrives.
• Run In Parallel: Specifies whether iterations within the round can execute in parallel.
• Tags: Allow grouping, organizing, and selectively executing specific rounds based on their assigned labels.
• Stages: An optional list of stages that let you vary concurrency within a single round (see Stages below).

Example

name: Example
rounds:
- name: ExampleRound
  startupDelay: 5
  numberOfClients: 10
  arrivalDelay: 500
  runInParallel: true
  tags:
    - test
    - performance

Stages

Stages let you define multiple concurrency levels within a single round. Each stage specifies its own numberOfClients and arrivalDelay, and stages are spawned sequentially in the order they are listed.

When stages are defined, they override the round-level numberOfClients and arrivalDelay — those fields are ignored and each stage's values are used instead.

Why Use Stages?

Without stages, changing the number of concurrent users requires creating separate rounds. Stages simplify this by letting you ramp load up, step it down, or spike it — all inside one round.

Common patterns:

• Ramp-up: Gradually increase load across stages.
• Spike test: Jump from low to very high concurrency, then back down.
• Natural ramp-down: Unlike tools such as k6, LPS does not require an explicit stage targeting 0 clients. When a client finishes its iteration, it is gone — staggered arrivals naturally produce a ramp-down.

Stage Attributes

• numberOfClients (required): Number of simulated users for this stage. Must be greater than 0.
• arrivalDelay (required): Time in milliseconds between each client's start within this stage. Must be greater than 0 when numberOfClients is greater than 1.
• startupDelay (optional, default: 0): Time in milliseconds to wait before this stage begins spawning clients (relative to the end of the previous stage). Must be greater than or equal to 0.

How Stages Execute

1. Stages are processed in order. Each stage's clients are pre-scheduled upfront before any begin executing.
2. The first client of a stage starts after all clients from the previous stage have been spawned (not completed), plus the current stage's startupDelay. A stage does not wait for the previous stage's clients to finish their iterations.
3. Within a stage, clients are spawned one after another, separated by the stage's arrivalDelay.
4. Spawning is sequential, but execution overlaps. A client begins executing its iterations as soon as it is spawned. While later stages are still spawning clients, earlier clients are already running their iterations concurrently.

Example: Ramp-Up

name: RampUpPlan
rounds:
- name: RampUpRound
  startupDelay: 5
  stages:
  - numberOfClients: 10
    arrivalDelay: 5000
  - numberOfClients: 50
    arrivalDelay: 1000
    startupDelay: 5000
  iterations:
  - name: GetRequest
    mode: D
    duration: 120
    httpRequest:
      url: https://www.example.com
      httpMethod: GET

What happens:

1. Stage 1 — 10 clients, each arriving 5000 ms apart (spawn window: 45000 ms).
2. Stage 2 — Waits 5000 ms after stage 1 finishes spawning, then 50 clients arrive 1000 ms apart.

All 60 clients share the same iterations and run concurrently once spawned.

Example: Spike Test

name: SpikeTestPlan
rounds:
- name: SpikeTestRound
  stages:
  - numberOfClients: 5
    arrivalDelay: 1000
  - numberOfClients: 100
    arrivalDelay: 100
  - numberOfClients: 5
    arrivalDelay: 1000
  iterations:
  - name: HealthCheck
    mode: D
    duration: 60
    httpRequest:
      url: https://api.example.com/health
      httpMethod: GET

What happens: A small baseline of 5 clients, followed by a sudden burst of 100 clients, then back to 5 — useful for testing how a system handles and recovers from traffic spikes.

Stages vs. Multiple Rounds

Validation Rules

• numberOfClients must be greater than 0.
• arrivalDelay must be greater than 0 when numberOfClients is greater than 1.
• startupDelay must be greater than or equal to 0.
• Stages support placeholders (e.g., ${myVar}) that are resolved at runtime.