Gatling is a well-proven and powerful open-source load testing tool. Using the intuitive Scala scripting language - it helps even first-time users get up and running fairly quickly.
It allows you to build upon basic tests created with our very own Test Builder with more advanced techniques such as:
- Full paramaterization of variables
- Capturing and verifying a wide variety of responses for manipulation & re-use
- Enables the development of complex scenarios
- And many more features
This guide has easy to follow steps that will ensure you are able to launch a test using Gatling with many users as well as getting to know Flood's intuitive user interface.
Download and unzip our Ready to Run Gatling script here. You will need to upload the .scala file in Step 6.
When first creating a test scenario or as Flood calls it a "Stream" - it's a good idea to seperate Streams and Floods by projects. Create a new project called MyGatlingProject by pressing the following button on the projects page:
Type in the Name field: MyGatlingProject
Click CREATE PROJECT
Click on the MyGatlingProject newly created project.
You will see the following screen:
Click Create Flood
Instead of using the Test Builder this time we will choose to upload an existing Gatling script that we've prepared.
For Test Type - select the Upload existing script, and Click CONTINUE
For Test Name - enter SimpleGatlingTest1
This is where you can name your test. If you end your test name with a number, Flood will automatically increment it if you run more than one test using this Stream.
For Test Scripts - click Choose Files and choose the sample file you downloaded and saved locally in Step 1.
Please wait until it is fully uploaded and the status of it has been marked as completed and the Uploaded At value is greater than 1 second.
For Test Parameters - Ensure the Gatling logo is highlighted and selected as this is a Gatling script.
For the purposes of this test please use the following settings:
- Threads: 250 - This is the number of concurrent users that will be run on each node.
- Duration: 5 - This the number (in minutes) you would like run the test for.
- Ramp Up: 0.5 - This is the amount of time (in minutes) that you would like the concurrent users to be injected. This is the overall time taken to get from 0 to 250 users.
For Advanced Parameters - we don't need to specify any in this guide however this can be useful if you would like to pass in command line arguments for more advanced scenarios.
OK, so now we are pretty much ready to go but first we need some cool cloud-based load injection infrastructure or as we like to call them - Grids.
For Choose Grid and Launch - click the +1 Launch Grid button.
This is where you are able to create and launch the infrastructure to run the test.
For Launch New Grid - select the following:
- Infrastructure: On Demand
- Size / Number of Nodes: 1
- Location / AWS Region: Australia (Sydney)
For Lifecycle - this is where we select how long the Grid will be up for. For the purposes of this short test we'll use teh following paramters:
- Start at: Start Now
- Stop after: 0.25 hours (15 minutes)
For Launch - this where we confirm the Grid launch parameters.
Confirm the settings and click LAUNCH GRID
Once you have your intricately researched (ahem or should I say random name generated) Grid name with the number of load injection nodes shown as a number of orange boxes within the Grid - we are just about ready to launch the test.
Click LAUNCH TEST
You will be automatically taken to the initial setup loading screen that shows you the status for creating the Grid, setting up the nodes, uploading all the Flood settings and test artefacts and then waiting for the first data points to be returned right after the test starts.
The following user interface for test execution will be presented to you indicating that the test is running and key metrics are being collated by the Flood platform.
The main components of the execution dashboard are explained below:
- Performance Metrics - For every test we focus on 3 main test metrics; (i) Concurrent Users, (ii) Response Time, and (iii) Transaction Rate. These are considered the most important metrics when performing a load test and can help determine if your target system is healthy or struggling.
- Logs - Full diagnostics logs are available and often yield helpful information on the state of the scenario. Here errors are aggregated from a load test tool perspective which can aid in diagnosis if the test encounters problems.
- Transactions - These transaction labels are the two HTTP requests that are setup in the Gatling script itself. Selecting each one will change the execution graph to display metrics specifically for the selected transaction. This is helpful if you would like to isolate a badly performing transaction during a test.
- Transaction Metrics - Response Time and Requests per Minute are displayed here for each transaction. These are both mean averages for the currently viewable timeframe of results.
- Error Rate - This area shows the percentage of passed / failed transactions as well as an arrow allowing you to drill-down to a sub page to see what error responses are being observed during the test.
You have just run your first Gatling load test using the Flood platform. We hope these steps were easy to follow and you are able to go on and do more advanced load testing scenarios.