Protocol load testing using Gatling
Run a protocol load test on BrowserStack Load Testing
Prerequisites
- BrowserStack Username and Access key. You can find these under your account profile.
- An existing Gatling script (written in Scala, Java, or Kotlin).
Run a test
Based on your preferred method of performing load tests, use one of the following methods:
Create a new test
You can start a new test either from the Quick Start page or the Load Tests page on the Load testing dashboard.
On the dashboard, click Create Load Test.

Enter a Test Name for your load test, select API Only, and click Upload scripts

Upload scripts
Upload your Gatling scripts.

BrowserStack Load Testing supports two modes for running Gatling tests:
Build tool project (Recommended)
ZIP your complete Maven, Gradle, or SBT project directory. The build config file (pom.xml, build.gradle, build.gradle.kts, or build.sbt) should be at the root of the ZIP or one level deep.
Your simulation files can be written in Scala, Java, or Kotlin.
Project structure example (Maven)
Project structure example (Gradle)
Project structure example (Gradle Kotlin DSL)
Project structure example (SBT)
Build-tool projects use the bundled Gatling 3.10.5 runtime. Ensure your project is compatible with this version. Maximum upload size for Gatling zips is 100 MB.
Standalone simulation files
If you don’t use a build tool, you can compress(ZIP) just the Gatling user-files/ directory structure containing your simulation files and resources. BrowserStack will execute them using the bundled Gatling OSS runtime (Gatling 3.10.5).
Your simulation files can be written in Scala, Java, or Kotlin.
Standalone project structure
Or with the user-files/ wrapper
Standalone mode uses the bundled Gatling 3.10.5 runtime. If your simulation requires specific library dependencies beyond the Gatling core, use a build tool project (Option A) instead. Maximum upload size for Gatling zips is 100 MB.
Select the simulation class
After uploading, BrowserStack automatically detects simulation classes (FQCNs) from your project. If one simulation class is found, it is auto-selected. If multiple simulation classes are found, select the one you want to execute from the dropdown. The simulation class is the fully qualified class name of your Gatling simulation to run, for example com.example.BasicSimulation.
Once you have verified the configuration, click Configure Load to move to the next step.
You can also run load tests using the sample scripts if you want to try out the feature before uploading your own files.
You can configure the following load parameters to customize your load test:
Run the test
After configuring your load parameters, click Run Test to start your load test.
For more information on analyzing your test results, refer to View protocol test results.
Download the BrowserStack Load Testing CLI
Download the CLI based on your operating system:
Generate the YAML file
Run the given command to generate the browserstack-load.yml file which contains the configuration required to define and run your load test:
Configure your Load Test
Open the generated browserstack-load.yml file and update it with the relevant test details. Here’s a sample configuration:
Specify number of virtual users
Set vus to the maximum number of virtual users to simulate during the test.
The maximum limit for this config is currently 1000. Contact us if you want to increase this limit.
Specify the simulation class
The files block identifies which Gatling simulation to execute. The requirements depend on your project type.
Build-tool projects (Maven/Gradle/SBT)
For projects using build tools, you must specify the simulationClass:
files:
simulationClass: com.example.MySimulation
-
simulationClass: The fully qualified class name (FQCN) of your Gatling simulation (for example,com.example.MySimulation). This field is required for build-tool projects. - The CLI detects build tools by checking for
pom.xml,build.gradle,build.gradle.kts, orbuild.sbtfiles in your project directory. - Your simulation files can be written in Scala, Java, or Kotlin.
Standalone projects (no build tool)
For standalone projects without a build tool, the files section is optional:
- If your project contains only one simulation class, the CLI automatically detects and uses it. No
filessection is needed. - If your project contains multiple simulation classes, specify the
simulationClassto select which one to run.
Project archiving
The CLI automatically zips your entire Gatling project directory for upload. You don’t need to create a ZIP file manually. The maximum upload size is 100 MB.
Backward compatibility
The deprecated testScripts field is maintained for backward compatibility:
files:
testScripts:
- com.example.MySimulation # Deprecated - use simulationClass instead
testScripts accepts a FQCN string (not a file path). Use simulationClass for new projects.
Set reporting structure
- Use
projectNameto group related tests under the same project on the dashboard. UsetestNameto group multiple runs of the same test. - Both
projectNameandtestNamemust remain consistent across different runs of the same test. - You can use the following characters in
projectNameandtestName:- Letters (A–Z, a–z)
- Digits (0–9)
- Periods (.), colons (:), hyphens (-), square brackets ([]), forward slashes (/), at signs (@), ampersands (&), single quotes (‘), and underscores (_)
- All other characters are ignored.
Example with load profile stages
Instead of using flat vus and duration, you can define a loadProfile with multiple stages:
You can configure the following load parameters to customize your load test:
Run the Load Test
Run the given command to start your test:
Check out the FAQs section to get answers to commonly asked questions.
View your test results
After running your load test, you can view detailed results on the Load Testing dashboard.
For more information on analyzing your test results, refer to View protocol test results.
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
Thank you for your valuable feedback!