Load modeling glossary

Load modeling is the art of describing how you want to drive traffic at a system. Getting this right determines whether your test answers the actual release question. This page defines the core concepts and shows how each maps to MaxoPerf configuration.

---

Virtual users (VUs)

Virtual users are the simulated clients executing your test scenario concurrently. Each VU follows the script from start to finish, recording timings as it goes. More VUs means more simultaneous load on the target.

See the canonical card: Virtual users — SEO Glossary.

In MaxoPerf: you set the VU count (and how it ramps) in the load profile section of a test. MaxoPerf distributes VUs across runner instances and managed locations.

Caution

VU count is not the same as request rate. A VU thinking for 5 seconds between requests generates very different throughput than a VU with zero think time. Always check the resulting RPS in your results, not just the VU count you configured.

---

Concurrency

Concurrency is the number of requests (or VUs) executing simultaneously at a given instant. It is related to, but not the same as, VU count: if a VU is waiting (think time), it is not making a concurrent request.

In MaxoPerf: concurrency appears in the run-detail charts as “active VUs” over time. Watch for concurrency dips during ramp-up — they indicate think time or slow upstream responses serializing the pipeline.

---

Open workload model

In an open workload model, new requests arrive at a fixed rate regardless of how many requests are currently in flight. If the system is slow and responses pile up, new arrivals still come in — simulating real internet traffic where users do not wait.

Open models are controlled by an arrival rate target (e.g. 100 req/s).

In MaxoPerf: k6’s constant-arrival-rate executor and Taurus throughput target both implement open workload semantics. Use open models when you need to prove a specific RPS target without artificially suppressing arrival under slow conditions.

---

Closed workload model

In a closed workload model, the total number of concurrent VUs is fixed. When a VU finishes a request (or wait), it immediately starts the next one. The request rate is therefore a result of the system’s speed, not a fixed input.

Closed models are controlled by a VU count and are the default in JMeter (thread groups) and most Taurus executors.

In MaxoPerf: most test profiles default to closed workload semantics. Be aware that under a closed model, a slow backend will reduce your measured RPS — which can make the system appear calmer than it really is.

Tip

For APIs that serve real user traffic at a target rate (e.g. checkout: 200 req/s), prefer an open model. For capacity tests where you want to hold X VUs and see how the system behaves, a closed model is natural.

---

Load profile

A load profile describes how VU count (or arrival rate) changes over the duration of a test. A typical profile has three phases: ramp-up → steady state → ramp-down. More complex profiles add steps, spikes, or recurring waves.

In MaxoPerf: the load profile is configured in the test-creation wizard or in the Taurus YAML execution block. A preview of the profile shape is shown before you run.

---

Ramp-up / ramp-down

Ramp-up is the initial phase where VU count (or arrival rate) increases from zero to the target level. Ramp-down is the symmetrical wind-down at the end. Gradual ramps reveal at which load level the system’s behavior changes — unlike instant-on tests that can mask the transition.

In MaxoPerf: ramp-up duration and shape (linear or stepped) are set in the load profile. MaxoPerf shows the ramp phases on the timeline chart so you can correlate behavior changes with load changes.

Caution

Skipping the ramp-up risks hitting cold-cache or connection-pool limits immediately, which distorts early results. Always ramp even for short tests.

---

Think time

Think time is a deliberate pause a VU takes between requests — simulating the time a real user spends reading a page, filling a form, or navigating. Without think time, VUs spin in a tight loop and generate far more load per VU than real users would.

In MaxoPerf: think time is configured per scenario in Taurus (think-time field) or in k6 (sleep() calls). Check your think-time assumptions in the test plan review.

---

Pacing

Pacing is a mechanism that enforces a minimum time between the start of one iteration and the next for a single VU. If the iteration finishes fast, the VU waits for the pacing interval before beginning the next one. If it finishes slow, the next iteration starts immediately.

Pacing differs from think time: pacing is measured from iteration start to iteration start, whereas think time is a fixed pause inserted within an iteration.

In MaxoPerf: pacing is supported via Taurus iterations + hold-for patterns and JMeter timer elements.

---

Arrival rate

Arrival rate is the rate at which new requests or transactions start, expressed in requests per second or transactions per minute. It is the primary control knob for open workload models.

In MaxoPerf: set the target arrival rate in the RPS-controlled throughput test recipe or via Taurus throughput or k6 constant-arrival-rate. The run result will show you whether the system sustained the target rate or fell behind.

---

Steady state

The steady state (also called sustained load phase) is the portion of a test where load is held constant at the target level. Metrics collected during steady state are the most comparable to production conditions.

In MaxoPerf: the load profile preview highlights the steady-state window. Failure criteria are most meaningful when evaluated over the steady-state window, not across the ramp phases.

---

Where to go next

• Metrics and results — what the numbers mean in run output.
• Foundations: open vs closed workload models — deep dive with examples.
• Foundations: ramp-up, think time, and pacing — configuration guide.