constantConcurrentUsers + throttle vs constantUsersPerSec for bounded Gatling heap at target RPS

Answer

For a variable‑latency system under test, the open‑workload profile constantUsersPerSec(r).during(d) bounds the Gatling load‑generator heap better than the closed‑workload profile constantConcurrentUsers(n).during(d) combined with throttle(...reachRps(r)...).

Likely explanation

With constantConcurrentUsers the same N virtual users stay resident for the whole simulation. If the SUT slows, those users block inside Gatling, retaining their session objects, stacks and any pending request state, so heap can grow with queueing depth. throttle only caps the offered request rate; it does not create users and does not verify that the cap is actually met, so a missed reachRps target is silent.

With constantUsersPerSec new users are injected at a fixed rate regardless of response time. The resident population approximates r × mean latency (Little’s law), which stays bounded even when latency spikes, because finished users are discarded and their memory reclaimed. The trade‑off is that arrivals do not back‑off, so a slowing SUT can be overloaded, but the load‑generator’s own heap remains smaller.

Confirmed facts (from Gatling behavior)

• throttle steps (reachRps, jumpToRps, holdFor) are rate limiters only; they do not generate users and do not raise an error when the target rate is not achieved.
• Gatling provides no built‑in assertion to fail a simulation on a missed reachRps step; you must add an external check (e.g., parse the simulation log or use a custom assertion) to detect the gap.
• Feeder replay strategies (queue, circular, random, shuffle) affect how feeder records are reused or exhausted, but they do not change the fundamental memory relationship between the two injection profiles; the feeder’s resident cost is added equally to both profiles.

Steps to verify for your case

1. Run a short soak (e.g., 2 min) at the target RPS with both profiles, using a slow SUT (induced latency) and a fast SUT.
2. After each run, force a full GC and record heap usage via GC logs, jstat, or container metrics.
3. Compare the reported reachRps value with the actual requests/sec from the Gatling report; a discrepancy confirms throttle acted only as a cap.
4. If feeder size is large, check whether it is loaded into memory (e.g., CSV feeder) or streamed; this adds a constant base cost but does not alter the relative heap advantage of the open profile.