Sample questions
Pf Load Model DesignDifficulty 1
In performance test load modeling, what is the core difference between an open workload model and a closed workload model?
- aThe open model always simulates more virtual users than the closed model, regardless of how the executor is configured
- bOpen model arrivals are independent of previous responses; closed model users each wait for a response first✓
- cThe open model can only be used for read-only endpoints, the closed model only for write endpoints
- dThe closed model always produces higher throughput than the open model at the same virtual user count
Explanation:Open model: arrival rate is the controlled, independent variable. Closed model: a fixed population of users each waits for its previous request to finish before sending the next, so arrival is coupled to response time.
Pf Load Model DesignDifficulty 2
Why is a load test built with a fixed number of virtual users (VUs) looping request → wait → request considered a closed system model?
- aBecause it always runs on a single load-generator machine, regardless of the target
- bBecause the number of VUs must be a multiple of the CPU core count on the generator
- cBecause it can only target REST APIs and not databases or message queues
- dEach VU issues its next request only after the previous response, capping the rate✓
Explanation:Closed model: the request rate is a downstream effect of VU count and response time, not an independently controlled input — that coupling is what defines it as closed.
Pf Load Model DesignDifficulty 2
What is 'coordinated omission' in performance testing?
- aA measurement artifact where a slow response makes the load generator send fewer requests, hiding the real latency✓
- bA configuration mistake where two load generators accidentally use the same data file
- cAn error where think time is accidentally left set to zero for every simulated user
- dA network issue where the load generator and target server clocks are not synchronized
Explanation:Coordinated omission happens because the measurement tool's own request pacing is 'coordinated' with (blocked by) the system's slowness, so exactly the worst delays are under-sampled.
Pf Load Model DesignDifficulty 1
What is 'think time' in a load test script?
- aThe time the load generator spends compiling the entire test script before execution starts
- bThe maximum duration a test is allowed to run before it times out
- cA deliberate pause simulating a real user reading or deciding before the next request✓
- dThe time the test tool waits before starting the first virtual user
Explanation:Think time is inserted between simulated user actions to mimic realistic human pacing, rather than firing requests back-to-back.
Pf Load Model DesignDifficulty 2
A team configures a load test to jump instantly from 0 to 5,000 virtual users at test start. Which load-modeling practice would most directly address the risk this creates?
- aReducing the number of assertions per request
- bUsing a ramp-up period that gradually increases users toward the target load✓
- cSwitching from HTTP/1.1 to HTTP/2 in the client library
- dIncreasing think time to a fixed 10 seconds for every request
Explanation:A gradual ramp-up avoids an instant load shock and lets the system (and observers) see how behavior changes as load increases, instead of hitting full load with no baseline.
Pf Load Model DesignDifficulty 2
Why might a team model request arrivals using a Poisson process instead of perfectly even, fixed-interval spacing?
- aReal traffic arrives in a bursty, random pattern that Poisson approximates better than a fixed interval✓
- bBecause Poisson arrivals are said to guarantee zero errors during the entire test
- cBecause fixed-interval spacing is technically not supported by any load testing tool
- dBecause Poisson modeling supposedly removes the need for any ramp-up phase
Explanation:Poisson-style random spacing better mirrors how independent real users actually arrive, compared to an artificially smooth, evenly-spaced synthetic pattern.