LoadRunner Rendezvous Points and Pacing Explained

Rendezvous Points and Pacing both affect timing in a LoadRunner scenario, but they solve different problems, and conflating them is a common source of confusion for people new to the tool.

Rendezvous Points: forcing simultaneous action

A lr_rendezvous("name") call placed in a script marks a point where a virtual user will wait until a Controller-configured threshold of other virtual users have also reached that same point — then all release together. This simulates scenarios where real concurrency genuinely spikes at one instant: many users clicking “buy” the moment a flash sale starts, or many automated jobs kicking off at the top of the hour. Without a rendezvous, a scenario’s virtual users reach that point at naturally staggered times (based on their own ramp-up and individual response time variance), which can’t reliably reproduce a true simultaneous-arrival spike.

Configuring rendezvous behavior in Controller

In the Controller scenario, you configure how a rendezvous releases: after all assigned Vusers arrive, after a percentage, or after a timeout regardless of how many arrived — the timeout option matters because without it, a rendezvous can stall indefinitely if even one virtual user never reaches it (due to an earlier failure), blocking the rest of the test.

Pacing: controlling iteration frequency

Pacing, configured per Vuser Group’s Run-Time Settings, controls the delay between one iteration finishing and the next starting for a given virtual user — directly analogous to the pacing concept covered for JMeter elsewhere on this site (and to this site’s pacing calculator). Common pacing modes: a fixed delay, a random delay within a range, or a fixed total iteration time regardless of how long the iteration’s actual work took (this last mode is the direct equivalent of “constant pacing” as opposed to “constant think time”).

Why the distinction matters

Rendezvous Points create a one-time, deliberate synchronization event within an iteration. Pacing governs the ongoing, repeated cadence of iterations over the full test duration. You can use either, both, or neither depending on what you’re testing — a steady-state capacity test typically relies on Pacing alone with no rendezvous; a spike/burst resilience test specifically needs a Rendezvous Point to manufacture the spike that Pacing alone cannot reliably produce.

Run-Time Settings: where pacing lives

Pacing, along with think-time behavior and iteration count, is configured in each script’s Run-Time Settings within Controller (or VuGen, for standalone testing) — separate from the script’s own code, meaning the same script can be paced differently across different scenario runs without editing the script itself.

A practical pairing

A common, realistic combination: pacing configured to produce steady, randomized iteration timing for the bulk of a test’s duration, with one or two specific Rendezvous Points placed at genuinely simultaneous real-world moments within the flow (e.g. “all users submit their order at once during a flash-sale opening”) layered on top — modeling both the steady background load and the deliberate spike within the same scenario.

Takeaway: Rendezvous Points answer “how do I force genuine simultaneity at one specific moment,” while Pacing answers “how do I control the steady rhythm of repeated iterations” — most scenarios need pacing; relatively few specifically need a rendezvous, and conflating the two leads to scenario designs that don’t model what you actually intended.