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.
"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:
- You place a Rendezvous Point at a specific step of your virtual user.
- You configure a threshold (for example, "500 VUs must be here").
- Each VU that reaches the rendezvous waits until the threshold is met.
- 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/