Gatling's Open vs Closed Injection Model: The Choice That Changes What Your Test Proves
Closed-model injection hides saturation behind polite virtual users. Here is how Gatling's open and closed steps differ, and how to pick one deliberately.
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Closed-model injection hides saturation behind polite virtual users. Here is how Gatling's open and closed steps differ, and how to pick one deliberately.
Learn how to compose realistic, multi-protocol load profiles in a single k6 script using scenarios and executors. Includes a worked example with HTTP, WebSocket, and gRPC flows, plus trade-offs like arrival-rate overshoot and graceful-stop cutoffs.
Learn how to combine Gatling’s CSV feeder with a constantUsersPerSec injection profile to run a steady‑rate load test, including setup, execution checks, and practical limitations.
I'm reviewing a Gatling simulation suite that was written against 3.9 and recently upgraded to 3.10. The tests hit state-dependent REST endpoints where each virtual user presents a session-specific token, and the payloads include timestamps that must be fresh on every iteration. My understanding is that before 3.10, the HTTP protocol cache was enabled by def
Goal Implement retry logic for a POST request that may return an HTTP 500, while avoiding duplicate writes to the target API. Constraints and Uncertainty Gatling does not ship a built‑in retry directive; users typically build retries using exec , when , and session variable checks. Without an idempotency key, a retry can cause the same POST to be processed t
Performance Measurement Constraint The goal is to establish a reliable baseline for latency when validating system sanity under defined load conditions. Uncertainty and Scope The constraint is maintaining a P95 latency below 50ms during a sustained 100 concurrent connection test using the documented sanity check feature. Which documented approach best handle
Cost‑efficient injection for low‑traffic Gatling scenarios The objective is to lower cloud instance‑hour expenses for Gatling tests that simulate a low‑traffic workload, such as one user generating requests at one per second. Constraints include using Gatling 3.10+ DSL helpers, accounting for JVM warm‑up and garbage‑collection pauses that may affect resource