Gatling Interview Questions: Open vs Closed Workloads and Reliable Assertions

A Gatling run can become quieter precisely when the service becomes slower. If the test holds a fixed number of active users, each user waits longer, fewer journeys finish, and the next journeys arrive more slowly. A reassuring latency chart can therefore answer a different question from the one the business asked.

For Gatling interview questions, start with the workload contract: open injection controls user arrivals; closed injection controls concurrent users. Then distinguish checks on individual responses from assertions on aggregate results. A useful pass condition must establish correct responses, sufficient exercised traffic, and acceptable latency together.

This article focuses on Gatling-specific decisions and original worked exercises, not a claimed employer question list or a measured capacity benchmark.

Gatling interview questions: what does the workload hold constant?

An open workload schedules new users independently of earlier users finishing. A closed workload maintains a target population of active users, replacing users that finish. These are different models of demand, not interchangeable ways to specify the same pressure. Gatling documents the distinction in its workload-model guidance.

For an externally driven public API, ask whether new work keeps arriving while previous work is slow. If so, an arrival-rate model often captures the relevant risk. For a fixed population of operators who wait for each operation before continuing, a concurrency model may represent the actual system better. Neither model is automatically more realistic without that behavioral premise.

The interview follow-up is usually more revealing than the definition: “What happens when latency doubles?” Say which quantity the injector preserves, which quantity is allowed to change, and what you would measure to confirm the configured behavior actually occurred.

Work through 40 arrivals versus 40 active users

Consider a deliberately simplified journey: one request, no think time, no retry, no client bottleneck. At steady state, the average number of active journeys is approximately arrival rate multiplied by average journey duration. This is accounting under stable conditions, not a formula for predicting an overloaded queue indefinitely.

With 40 arrivals per second and a 0.25-second mean duration, approximately 10 journeys are active. At a two-second mean duration, approximately 80 are active if arrivals remain 40 per second and the system reaches another stable regime. Increasing occupied users is part of the experiment, not necessarily a scripting bug.

With 40 concurrent users, the corresponding idealized completion rates are about 160 journeys per second and 20 journeys per second. Slow responses reduce turnover. The second test does not prove the service can sustain 40 independent arrivals per second merely because “40 users” appears in its configuration.

Controlled input	Fast case: 0.25 seconds	Slow case: 2 seconds	Interpretation
40 new users/second	About 10 active users	About 80 active users	Occupancy grows with journey duration
40 concurrent users	About 160 journeys/second	About 20 journeys/second	Offered replacement traffic falls as users wait

Real journeys introduce pauses, multiple requests, branches, connection limits and failures. Add those explicitly before using the arithmetic to size a generator. During sustained overload, unfinished work can grow without a stable average; quote a time window and show the backlog rather than asserting equilibrium.

Translate the premise into injection syntax

The injection reference separates Java DSL methods such as injectOpen and injectClosed. An open profile can use constantUsersPerSec(40).during(60). A closed profile can use constantConcurrentUsers(40).during(60). Their units belong in the explanation and in the run configuration.

An arrival rate describes virtual-user starts, not automatically HTTP requests per second. A user may send several requests, loop, pause, or stop after a failed prerequisite. If each successful journey makes three calls, multiplying users by three gives an expectation only when every relevant branch actually executes those calls.

Likewise, a 60-second injection period is not necessarily a 60-second end-to-end run: users already started may still be completing their scenarios. A separately configured maximum duration can terminate unfinished work. The simulation reference describes run-level controls; account for their effects before interpreting counts.

Do not mix an open and closed profile inside one population to make the graph look right. State the chosen model, then define separate experiments if both business situations matter.

When asked for a ramp, clarify whether the requirement is a total user count spread over time or a rate that increases over time. A ramp of 600 users over a minute is not a ramp that reaches 600 users per second. Write the units next to every parameter and estimate the area under the arrival-rate curve before running the test. This small arithmetic check often exposes a configuration that would otherwise send far more traffic than the authorized experiment intended.

What is the difference between a check and an assertion?

A check inspects a response or extracts data during a virtual user's execution. An assertion evaluates statistics over the completed simulation. A response can satisfy a transport expectation yet still be wrong for the business; an aggregate can look healthy while a critical endpoint fails.

Gatling's checks reference covers extraction and validation. The HTTP checks reference documents protocol-specific checks. For an order lookup, verifying status 200 is useful, but verifying the returned order identity and expected state can be essential. Otherwise a cached error envelope or the wrong account's data may count as a successful response.

Keep assertions independent enough to diagnose failure. A latency threshold answers how long recorded operations took. An error threshold answers how many failed the configured checks. A count threshold establishes that the named request was actually exercised. None replaces the others.

Build an assertion set that can fail for the right reason

The following Java DSL example is a documentation-based illustration for a controlled test endpoint. It was not executed as a Gatling benchmark here. localhost:8080 must be your authorized test service, with /health returning status 200 and JSON {"status":"ok"}. Pin the Gatling version and compile it in the project's normal build before using it as a gate.

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;
import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

public class HealthLoad extends Simulation {
  HttpProtocolBuilder protocol = http
      .baseUrl("http://localhost:8080");

  ScenarioBuilder journey = scenario("single-health-request")
      .exec(http("health")
          .get("/health")
          .check(status().is(200),
                 jsonPath("$.status").is("ok")));

  {
    setUp(journey.injectOpen(
        constantUsersPerSec(40).during(60)))
      .protocols(protocol)
      .assertions(
        details("health").allRequests().count().gte(2400L),
        details("health").failedRequests().percent().lte(1.0),
        details("health").responseTime().percentile(95).lte(500)
      );
  }
}

The 2,400 count follows from this exercise's single-request journey and 40-by-60 schedule. The one-percent failure and 500-millisecond p95 bounds are illustrative requirements, not Gatling recommendations or universal service objectives. Choose limits before looking at the result.

The assertions reference defines explicit percentile selection, request scopes, counts and percentages. Prefer percentile(95) when you mean p95; numbered percentile aliases are configurable. Scope important endpoints explicitly so fast health traffic cannot dilute a slow checkout path.

Falsify the gate before trusting a green run

Try three deliberate faults in an isolated, authorized environment. First, make the endpoint return the wrong JSON with status 200: the semantic check should expose it. Second, introduce controlled delay: the latency gate should fail without silently lowering the arrival target. Third, prevent part of the scenario from reaching the named request: the volume condition should reject the under-exercised result.

These are proposed verification steps, not tests claimed to have run. Their purpose is to test the measurement system itself. A gate that never fails when its requirement is violated is decoration, even if its report looks precise.

For example, imagine 2,400 fast responses but 480 contain invalid business results. A latency-only gate may pass; the correctly configured failure gate sees 20 percent. Conversely, 1,200 valid fast responses do not establish the planned 2,400-request exercise. A count gate catches that shortage, although totals alone still cannot prove the intended arrival schedule was maintained throughout the minute.

Why can percentiles and groups mislead?

A percentile needs a named population, time interval and measurement boundary. Ask whether a reported chart describes all recorded attempts, successful requests, or a particular group. Rapid rejection can shorten observed durations while useful throughput collapses. Read latency beside error counts and completed business outcomes, not as a standalone health score.

Do not average p95 values across workers or time buckets and call that the overall p95. Aggregation needs compatible underlying observations or an appropriate mergeable distribution. Also inspect sample size: a rarely executed branch can have a numerically precise percentile with weak evidence about its tail.

Group timing deserves its own explanation. Gatling distinguishes a group's total duration from its cumulated request response time; pauses can separate these meanings. The timings documentation is the reference when an interviewer asks whether a group assertion proves a user's entire journey met its deadline.

Separate service limits from generator limits

Record configured arrivals, observed user starts, named-request counts, completion counts, failures and unfinished work on the same timeline. Then add generator CPU, memory, network and connection evidence. A busy application and a busy injector can produce similar-looking shortfalls, but require different fixes.

Data setup is another hidden boundary. A queue feeder can exhaust its records; repeatedly reusing one account can create unrealistic contention or cache locality. The feeders reference describes data-consumption strategies. Choose them according to the scenario rather than switching to random reuse solely to stop an exhaustion error.

Preserve the first failure and the test configuration. A rerun after caches warm, data changes, or instances scale out is a different observation. In CI, keep the assertion exit status, simulation version, target build, environment, timestamps and report together. Distinguish “service failed its objective” from “experiment was invalid.” Both can block release, but their explanations differ.

Practise the evidence behind a load-test answer

For each one, explain the controlled input, the result population and a fault that would falsify your conclusion.

Question	Gatling practice focus
Validate and Assess Performance Benchmarks	Reject an under-delivered workload before comparing latency.
Design tests to measure latency impact	Define the request population and measurement interval.
Debug a slow concurrent network server under load	Separate active users, queues and completion throughput.
Design a Test Orchestration System	Preserve run configuration, assertion failures and artifacts.
Troubleshoot CPU, latency, and DNS issues	Distinguish injector or network limits from application delay.

The strongest Gatling answer explains why the load represents the business, what each check proves, and which observation could make the result invalid. Return to the QA and SDET guide and rehearse one release decision with those three boundaries explicit.

Sources and Further Reading

• Gatling: workload models
• Gatling: injection
• Gatling: assertions
• Gatling: checks
• Gatling: HTTP checks
• Gatling: simulation
• Gatling: timings
• Gatling: feeders

Research checked September 21, 2026. SDK details should be verified against the version pinned by your project. Numerical workloads and gates above are illustrative, not measured capacity claims.