Feeders & throttling

Traffic modelling

Drive each iteration from a shared data feeder and throttle how fast a VU may fire, so a big pool doesn't outrun your intended per-user pace.

Browse all 52 demos 12 categories
Run it
$ loadr run examples/17-feeders-and-throttle.yaml
examples/17-feeders-and-throttle.yaml
# Feeder strategies (Gatling: sequential / random / shuffle, plus JSON feeders)
# and a global request-rate ceiling (Gatling throttle / reachRps).
name: feeders-and-throttle
description: random/shuffle/JSON data feeders + a hard RPS cap

defaults:
  http: { base_url: https://api.example.com }

data:
  # Each VU shuffles the user list once, then walks it in that order.
  users:
    type: csv
    path: data/users.csv
    mode: per_vu
    pick: shuffle
    on_eof: recycle

  # A uniformly random SKU every time it's referenced (never exhausts).
  skus:
    type: json
    path: data/skus.json
    pick: random

scenarios:
  steady_browse:
    executor: constant-vus
    vus: 50
    duration: 5m
    # No matter how many VUs or how fast the target is, never exceed 200 req/s
    # in aggregate — the Gatling `throttle` / `reachRps` behaviour.
    throttle: { requests_per_second: 200 }
    flow:
      - request:
          name: login
          method: POST
          url: /login
          body: { form: { user: "${data.users.username}", pass: "${data.users.password}" } }
          extract:
            - { type: jsonpath, name: token, expression: "$.token" }
      - request:
          name: product
          url: "/products/${data.skus.sku}"
          headers: { Authorization: "Bearer ${token}" }
          checks: [ { type: status, equals: 200 } ]

thresholds:
  # With the throttle, http_reqs/s should hover at the ceiling, not above.
  http_reqs: [ "rate<=205" ]
  http_req_duration: [ "p(95)<400" ]

View raw: examples/17-feeders-and-throttle.yaml

What it shows

  • Shared vs per-VU feeder modes
  • Per-VU throttle keeps pacing realistic
  • Deterministic replay of a dataset