---
title: 'Rendezvous Points: Simulating Real Simultaneity, Not Just a Ramp-Up'
url: https://blog.octoperf.com/rendezvous-points-simulating-real-simultaneity-not-just-a-ramp-up/
date: '2026-06-29'
authors:
- qhamard
categories:
- Innovation
tags:
- Load Testing
- Performance Testing
- JMeter
- Runtime
description: Why a ramp-up is not a load spike, and how OctoPerf's Rendezvous Points let you natively synchronize virtual users to reproduce real-world burst events like flash sales, ticket drops, or mass logins.
---

# Rendezvous Points: Simulating Real Simultaneity, Not Just a Ramp-Up

This is the fourth post in our "Features Sitting Idle" series, where we explore OctoPerf features that are powerful, already available, and yet often replaced by manual workarounds.

![Features Sitting Idle - Rendezvous Points](https://blog.octoperf.com/img/blog/features-sitting-idle/rendezvous-points-octoperf.png)

## "A Ramp-Up Is Not a Load Spike."

The distinction matters, and it is often overlooked in test scenarios.

Teams that need to simulate a true **simultaneous spike** - flash sales, ticket drops, mass logins at a specific time, scheduled batch openings - usually end up working around the problem instead of using the tool's native support for it.


## The Patterns We See Most Often

A few situations come up regularly when we look at customer scenarios:

- **Unsure which control to use.** Users who need to release a fixed number of virtual users at regular intervals and aren't sure whether ramp-up, pacing, or a dedicated component is the right approach.
- **Fragile JSR223 workarounds.** Teams that know they need simultaneity but aren't sure how to achieve it without custom scripting, so they end up writing JSR223 workarounds that are fragile to maintain.
- **Load profiles that look right on paper.** Profiles that look correct in a slide but don't reproduce the burst behavior of real-world events like a sale opening or a scheduled batch.

The common thread: **a ramp-up gradually increases the number of active users.** It's useful for stabilizing load, but it is not the same thing as forcing N users to hit the same action at the same precise moment.

## What Rendezvous Points Do

Rendezvous Points are a native component in the OctoPerf designer. No scripting required.

The mechanic is simple:

1. You place a Rendezvous Point at a specific step of your virtual user.
2. You configure a threshold (for example, "500 VUs must be here").
3. Each VU that reaches the rendezvous **waits** until the threshold is met.
4. When the threshold is reached, **all VUs proceed together**.

The result is a true simultaneous burst at exactly the point in the user journey where it matters.

## When to Use It

Rendezvous Points are particularly valuable in scenarios like:

- **Flash sales and ticket drops.** Tens of thousands of users hitting "Add to cart" within the same second.
- **Mass logins at scheduled times.** The 9:00 AM intranet rush, the start-of-shift access bursts, mass authentication after an outage.
- **Scheduled batch interactions.** Cron-triggered consumers all calling an API at the same minute.
- **Concurrent write contention testing.** Forcing N users to update the same record simultaneously to expose locking and concurrency issues.

In each case, a ramp-up smooths the load out exactly when you don't want it smoothed out.

## Combining Ramp-Up and Synchronization

A useful pattern that often gets missed: **you can combine ramp-up and Rendezvous Points** in the same scenario.

For example:

- Step ramp-up to 1,000 active users over five minutes to stabilize the system.
- A Rendezvous Point at the "checkout" action that releases 1,000 VUs simultaneously.
- A think time before the next iteration so the burst repeats every minute.

This is much closer to how real spike events look in production: a steady underlying load, with periodic synchronized bursts on a specific action.

## Why It Beats a JSR223 Workaround

The JSR223 workarounds we see in the wild usually try to recreate this behavior with timers, counters, or shared variables. They work, until:

- The number of load generators increases and the shared state stops being shared.
- A new engineer joins the team and can't read the script.
- The threshold changes and the workaround needs to be rewritten.

A native Rendezvous Point doesn't have those failure modes. It scales across load generators, it's visible in the designer, and changing the threshold takes two seconds.

## Final Reflection

Realistic load testing isn't only about hitting the right RPS or the right concurrent user count. It's also about reproducing the **shape** of the traffic.

If your scenarios always look like a smooth ramp-up, you're testing the easy case. Real-world traffic is bursty, and Rendezvous Points are the tool to model that without leaving the designer.

Full documentation: [api.octoperf.com/doc/design/edit-virtual-user/action-types/logic-actions/rendezvous/](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/logic-actions/rendezvous/)