Parent page: Load/Performance Testing with NeoLoad

In a few of my recent posts I mentioned importance of avoiding unrealistic stress in test sessions. – And I also mentioned that there are situations when we indeed want to explore behavior of the application being under stressing load. But first of all, let’s agree on some definitions.

Stress Test – A performance test focused on determining or validating performance characteristics of the product under test when subjected to workload models, and load volumes beyond those anticipated during production operations. Stress tests may also include tests focused on determining or validating performance characteristics of the production under test when subjected to workload models and load volumes when the product is subjected to other stressful conditions, such as limited memory, insufficient disk space or server failure. – Scott Barber

Spike Test – A performance test focused on determining or validating performance characteristics of the product under test when subjected to workload models and load volumes that repeatedly increase beyond anticipated production operations for short periods of time. Spike testing is a subset of stress testing. – Scott Barber

With this post, I’ll look into a particular pattern of stress – a “sudden” spike of simultaneous requests to the server, targeting same set of resources or using same API functions. In its simplest form that would be hitting the same web-page. Other common occurrences – login spike, voting spike, and bulk requests.

So how can we simulate that? Starting all virtual users exactly at the same time might do the trick for a few rounds, but they will eventually “drift apart” on the  timeline. And if your load profile consists of several load scripts, the trick won’t work at all. The virtual users simulating  spike must “gather” at the certain point, and then simultaneously fire requests.

To achieve that, with NeoLoad, we can actually set a “rendezvous point” .

I’m using the same sample script I presented in this post, – a simulation of an online payment, – but with a “rendezvous point” modification.

After setting rendezvous points, we need to define “Rendezvous Policy” –

• Release settings allow defining density and timing of simultaneous requests. When enough of concurrent users reached the rendezvous point, they are “released” – let go forward and fire the requests.
• Timeout is needed to avoid endless waiting for the users who “got stuck” somewhere on the way.