The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once. A SyncTimer can thus create large instant loads at various points of the test plan. Here’s how you can use JMeter SyncTimer for Load Testing.
An Example – A Registration System
Let’s say you’re load testing against a Racing Registration system. You have a JMeter script that pulls user information from a CSV file and your Thread Group has the following steps:
- Contact Registration service, get the page for login.
- Login to Service
- Execute tasks in Racing Registration system, filling out forms
- Logout of Registration Service
JMeter runs through each of those steps as a separate thread and the script works.
The problem is that your test isn’t quite accurate when compared to the behavior of your users in real life. This is a Registration system and your end users are logging in and authenticating minutes before they race opens up for registration, then stampeding when the actual system when Registration opens.
In modeling the real world scenario you don’t have the login function being hammered, because you don’t have thousands of users authenticating at simultaneously. When you load testing with JMeter the first steps are to login making authentication a bottleneck. It fails quickly when you load test with hundreds of users over starting up at the same time. Now you might go spend time improving your authentication service while in reality you just wasted a lot of cycles because the focus should have been on the registration service. This is a problem in your load test scenario.
How can you build a JMeter load test that separates out the authentication and registration, maintaining the authentication session and not falsely overtaxing your authentication service?
Using JMeter SyncTimer for Load Testing
You can use ‘Synchronizing Timer‘ element of the JMeter that will wait for all the users to login and then move forward to the next step (Registration System).
You can create your script in following structure:
- HTTP Request for Contact CAS server, get login ticket
- HTTP Request for Login to CAS
- Synchronizing Timer [Set the ‘Number of Simulated Users to Group by’ to 0 and Timeout based on your requirement [Recommended value to set is ‘300000’ i.e 5 minutes]. Do not set Timeout to ‘0’ otherwise your test will remain in running state forever if any of the users gets failed in the previous step]
- HTTP Request for Execute tasks in Registration system
- HTTP Request for Logout of CAS
When the test completes ‘HTTP Request for Login to CAS’ step then it will wait for all the users to reach that step before moving to ‘HTTP Request for Execute tasks in Registration system’ step.
If you need information related to other JMeter elements you can refer to the JMeter knowledge base to get all the critical information in one place.
With RedLine13, you can run a JMeter Load Test with your JMX script of any mobile application, web application, or API.