Andréi Guchin is an Electrical Telecommunication Engineer who has been working at Abstracta for more than 7 years. During this time he has participated in many Performance Engineering projects in which he has gained solid experience developing tasks like monitoring, data analyzing, scripting and executing tests, but also in planning and managing this type of projects. Andréi has also worked as a developer on JMeter plugins development projects.

Become a JMeter and Continuous Testing Pro

Start Learning
Slack

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)
Nov 10 2021

Load Testing a Rendezvous Point with JMeter: A Guide

Back when I was in college, there were some courses with a limited number of seats that required enrollment. I have unpleasant memories of those times, since when the enrollment period opened up, all the students would enter the university website at the same time and attempt to sign up for the course. Guess what? The system would always crash. Irritation doesn’t even begin to describe our feelings. We suffered from extremely slow system response times. Even worse, sometimes we’d encounter server or application errors that caused many of us to miss the registration window.

Nowadays I realize that these performance problems in the system could have been prevented by doing load tests with a rendezvous point. Let’s see how.

What is a Rendezvous Point?

“Rendezvous” is a French term that refers to a planned meeting between two or more parties at a specific time and place. In performance testing, a rendezvous point is a specific place in a workflow, where the virtual users meet before running a particular step, process, or functionality of the workflow, all at the same time. In other words, the virtual users will wait for the others at the rendezvous point in order to proceed all together.

The rendezvous point is used to test the system behaviour under a high load peak. The  peaks could be, for example, all the students trying to subscribe to a particular class at the same time or a big group of fans trying to buy the best tickets for a music concert. Not using it may result in not putting enough pressure on the system in that specific testing step. 

The rendezvous point could also be used to test the application behaviour when two users (or more) try to access the same object or functionality exactly at the same time. For instance, what happens in the music concert example when two different people try to buy the last remaining ticket at the same time? This particular situation is a bit difficult to simulate by running two virtual users with a typical automated workflow, as different threads may have different response times and they will probably not “arrive” at the same time to the specific functionality to test.

 

Below, we will see how to simulate a rendezvous point using JMeter and BlazeMeter.

Testing a Rendezvous Point with JMeter

JMeter has an element that behaves exactly as a rendezvous point. This element is the Synchronizing Timer

As described in the documentation, this element blocks threads until X number of threads have been aggregated, and then they are all released at once. Therefore by adding a Synchronizing Timer in a request, you are setting a rendezvous point in the workflow just before that request.

For example, in the image below you can see the threads will perform the “home” request once they are created and then will wait for the remaining threads to make the “solutions” request all together.

 

The Synchronizing Timer element has two fields to configure: one is the number of threads (virtual users) to wait before releasing them all, and the other is a timeout that releases the waiting threads after a specific time, even if not all the virtual users have reached the point.

But what happens when distributing the load in remote testing? At first you may think that the timer will work only at server level, by waiting for the threads that are only generated on each JMeter server. However this is not the case. When remote testing, the Synchronizing Timer will create a global scope for waiting for the users from all the JMeter servers, and releasing them all together.

This also works in BlazeMeter. If we have, for example, two engines running 500 virtual users on each, we can set the synchronizing timer to wait until the 1000 virtual users reach the rendezvous point and then release them all at once.

Synchronizing Timer JMeter Example

Let’s give more details about how to configure the timer and how it behaves when executing, using the example from the previous screenshot. 

 

Consider an automated workflow with two steps:

  1. Go to the Homepage of the site.
  2. Click on the “Solutions” button.

We want to run the workflow in a way that the users go to the Homepage, stay there waiting and then all the users hit the “Solutions” button, together.

In order to do this, we should add a Synchronizing Timer in the “solutions” request:

  1. Right click in the Solutions HTTP Request
  2. Go to Add/Timer and then click on Synchronizing Timer 
  3. Configure the timer. For this example we will leave the two timer fields with their default values (“0” both) so the timer will wait for all the virtual users before releasing them all at once. If we set the values with other numbers, for example 5 simulated users to group by and 1000 milliseconds of Timeout, the Timer will wait for up to 1000 milliseconds for 5 virtual users and execute the request all together.

We can run a simple test to verify that it is working properly. For example, if we execute a JMeter test with 5 virtual users and a 2 minutes ramp up, you will see something like the image below.

Looking at the start time of each request, you can see that the “home” requests are executed at a different time (following the 2 minutes ramp up), but the first requests of the “solutions” step (solutions-0) are executed all at the same time, just next to the last “home” request.

On the other hand, if we run the same test but distribute the load between two JMeter servers, we will see a similar behaviour (see below image) verifying what we explained before about the scope of the timer when remote testing.

 

See how, once again, the “home” requests are executed at different times but the “solutions-0” requests run all at the same time, regardless of which server they are executed from.

Looking at the Transactions per Second graph we can see how the peak load is generated after all the “home” requests are executed:

 

Finally, if we run the same script with more virtual users (let’s say 500 vus with a two min ramp up) in BlazeMeter, we will see a behaviour that is shown in the following graphs:

 

Note how the Hit/s value increases significantly at the end of the test. 

Looking at the below image it can be seen that this increment is done after the 500 virtual users execute the “home” request and that all the requests from the green peak refer to “solutions” requests.

That’s it! After running your rendezvous point test in JMeter, you can scale it in BlazeMeter. Sign up now.

 

   
arrowPlease enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!