Load modeling glossary

Load modeling describes how you drive traffic at a system. If you get it wrong, your test does not answer the release question you actually have. This page defines the core concepts and shows how each maps to MaxoPerf configuration.

---

Virtual users (VUs)

Virtual users are the simulated clients that run your test scenario concurrently. Each VU follows the script from start to finish and records timings as it goes. More VUs put more simultaneous load on the target.

See the canonical card: Virtual users in the 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 that thinks for 5 seconds between requests generates very different throughput from a VU with zero think time. Always check the resulting RPS in your results as well as the VU count you configured.

---

Concurrency

Concurrency is the number of requests (or VUs) running at the same instant. It differs from VU count: a VU that is waiting (think time) 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 point to think time, or to slow upstream responses that serialize the pipeline.

---

Open workload model

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

An arrival rate target (e.g. 100 req/s) controls an open model.

In MaxoPerf: k6’s constant-arrival-rate executor and Taurus throughput target both implement open workload semantics. Use an open model when you need to prove a specific RPS target and do not want slow responses to hold back new arrivals.

---

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 starts the next one straight away. So the request rate follows from the system’s speed. It is not a fixed input.

A VU count controls a closed model. It is the default in JMeter (thread groups) and most Taurus executors.

In MaxoPerf: most test profiles default to closed workload semantics. Under a closed model, a slow backend reduces your measured RPS, which can make the system look calmer than it 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 hold X VUs and watch how the system behaves, a closed model fits.

---

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 repeating waves.

In MaxoPerf: you configure the load profile in the test-creation wizard or in the Taurus YAML execution block. MaxoPerf shows a preview of the profile shape 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 matching wind-down at the end. Gradual ramps show the load level at which the system’s behavior changes. Instant-on tests can hide that transition.

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

Caution

If you skip the ramp-up, you can hit cold-cache or connection-pool limits at once, which distorts early results. Always ramp, even for short tests.

---

Think time

Think time is a deliberate pause a VU takes between requests. It stands in for 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: you configure think time per scenario in Taurus (think-time field) or in k6 (sleep() calls). Check your think-time assumptions in the test plan review.

---

Pacing

Pacing 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 out the pacing interval before it begins the next one. If it finishes slow, the next iteration starts at once.

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

In MaxoPerf: you get pacing through 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 main control for open workload models.

In MaxoPerf: set the target arrival rate in the RPS-controlled throughput test recipe or with Taurus throughput or k6 constant-arrival-rate. The run result shows whether the system held the target rate or fell behind.

---

Steady state

The steady state (also called the sustained load phase) is the part of a test where load stays constant at the target level. Metrics from the steady state compare best with production conditions.

In MaxoPerf: the load profile preview highlights the steady-state window. Failure criteria mean the most when MaxoPerf evaluates them 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: details with examples.
• Foundations: ramp-up, think time, and pacing: configuration guide.