Distributed Load Testing with Gatling and Testkube on Kubernetes

Today's applications differ from those of a few years ago. Most applications are becoming more complex as they migrate to a microservices-based design. Consider an e-commerce platform with microservices for order tracking, payments, and other functions. The load experienced by such applications changes significantly depending on the time of day, shopping sales, and festivals. Therefore, keeping the application up and functioning during such periods is important.

Consequently, load tests are crucial for validating your apps' stability and availability. Distributed load testing is further used to replicate complex real-world situations.

In the first article in this series, we walked through how to set up a simple Gatling load test with Testkube. In this blog post, we will explore the requirements for distributed load testing, the challenges associated with it, and a detailed guide on implementing Gatling distributed load testing with Testkube. 

Need For Distributed Load Testing

In certain situations, such as simulating large numbers of users or traffic from multiple geographical locations, it is necessary to use a distributed approach. A distributed testing approach involves running load tests across multiple machines to simulate realistic user behavior and push the application to its limits. Some of the benefits include:

• Relevant Traffic Simulation: Tests can more accurately indicate user behavior by simulating traffic from various IP addresses and geographical locations.
• Scalability: Load tests must scale with the applications. Distributed testing facilitates the simulation of a greater number of concurrent users.
• Bottleneck Identification: By distributing the load, you can identify specific bottlenecks in your infrastructure, resulting in more accurate optimizations.
• Distributed Testing: Gatling supports distributed load testing, which lets you replicate traffic from various locations to test applications with users from different locations.
  

Distributed Load Testing with Gatling

Gatling is a load testing solution tailored to analyze and assess the performance of web applications under various load conditions. Distributed load testing analyzes how an application operates under huge user loads by simulating concurrent traffic across multiple machines or nodes.

When using a distributed setup approach, Gatling manages the execution of test scripts on several nodes, each adding to the total load on the intended application. This not only improves test scalability but also allows for more accurate detection of performance bottlenecks.

In addition to replicating real-world activity, Gatling can help identify possible bottlenecks and performance issues, allowing you to resolve them before they adversely impact users.
Gatling can run as a standalone tool and even supports integration with various build tools, such as Gradle and Maven, and CI/CD tools, like GitLab and Jenkins.

Refer to the Gatling documentation for more information.

Challenges of Distributed Gatling Tests

While Gatling is powerful, distributed load testing introduces complexities that require attention:

• Resource Limitation: Even with distributed testing, the testing infrastructure's hardware resources limit the process. This can make it challenging to replicate large numbers of concurrent users. 
• Complex Configuration: Setting up distributed tests necessitates careful configuration of test scripts and infrastructure. Static test configurations lack flexibility, making adapting to many production-like scenarios difficult.
• Aggregation of Results: Combining results from multiple machines can be complex and error-prone. To obtain reliable test results, it is important to combine data from all nodes correctly.
• Infrastructure Management: Managing the infrastructure for distributed testing, such as synchronizing multiple machines and deploying tests across them, adds another level of complexity to the testing process. 

Distributed Load Testing with Testkube And Gatling

Testkube enhances distributed load testing by integrating seamlessly with Kubernetes, allowing you to create comprehensive test workflows with different processes. Working with Testkube is as simple as integrating a load testing tool like Gatling and configuring Test Workflows to manage and execute tests across multiple nodes efficiently. 

Testkube distributes these tests to replicate real-world traffic, allocating resources through its job scheduler. Following the tests, Testkube aggregates the results from all nodes, providing a centralized UI for monitoring and analyzing logs, performance metrics, and test artifacts, ensuring a thorough evaluation of the application's performance under load.

We’ll now look at creating a simple Gatling test workflow using Gradle in Testkube. The test code and related files are in our Gatling Test repository. 

For a visual walkthrough of this tutorial, you can watch the accompanying video below before diving into the written instructions and prerequisites.

Prerequisites

• Get a Testkube account.
• Kubernetes cluster - we’re using a local Minikube cluster.
• Testkube Agent configured on the cluster.

Once the prerequisites are met, you can launch a target Kubernetes cluster with a configured Testkube agent.

Creating a Test Workflow

Navigate to the test workflow section and click the “Add New Test Workflow” button. 

A “Create a Test Workflow” dialog provides four options to create a test workflow:

• Create from Wizard: This option displays a dialog box that guides you through the steps of creating a new test workflow. 
• Start from an Example: This option allows you to use a pre-configured example, such as k6, Playwright, Cypress, Playwright, or Postman.
• Combine Existing Workflows: This option allows you to combine and run various existing test workflows sequentially or simultaneously.
• Import a Workflow from YAML: This option allows you to import a test workflow using a YAML definition.

Create this workflow by choosing the “Start from an example” option.

We’ll choose “Gradle” to create this test workflow for Gatling. As mentioned in the test, we're using a customized Test workflow as shown in test.yaml file. We shall discuss the content of this spec later in this blog post.

Click on the “Create & Run” button to create and run the test workflow.

Executing Test Workflow

Because this is a distributed test workflow, you will be asked to provide values for the duration, number of workers, and virtual users before executing the test workflow. 

Enter the parameter values for duration and the number of virtual users and workers. If you don’t provide anything, it will choose the default values mentioned in the spec file.

Once these parameters are set, click ”Run” to start the load test with the configured settings. The Test Workflow will start executing based on the parameter values that you have provided.

Based on the number of workers provided, you can see that Gatling load tests run simultaneously on that many workers. To view more information about each execution, simply click on any of the workers.

Navigate to the "Artifacts" page to view the test logs and reports. Logs and reports are generated for each worker.

Clicking on any of the reports will open them in a new tab. Below is what a typical distributed load test report looks like.

This was a simple demonstration of creating and running Gatling distributed load tests with Testkube. To get the most out of test workflows, create custom workflows and import them into Testkube. 

Read our blog post on running distributed Gatling tests on Testkube to perform large-scale distributed load tests

Understanding Gatling Test Workflow File

Let’s understand the Gatling Test Workflow used for configuring and executing this test:

kind:TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: gatling-testkube-distributed
  namespace: testkube
  labels:
    docs: example
spec:
  config:
    duration:
      type: string
      default: 5s
    vus:
      type: integer
      default: 10
    workers:
      type: integer
      default: 3
  content:
    git:
      uri: https://github.com/kubeshop/testkube-examples.git
      revision: main
      paths:
      - Gradle/Gatling/Distributed
  container:
    env:
    - name: vus
      value: '{{config.vus}}'
    - name: duration
      value: '{{config.duration}}'
  steps:
  - name: Run test
    parallel:
      count: config.workers
      transfer:
      - from: /data/repo/Gradle/Gatling/Distributed
      use:
      - name: distribute/evenly
      container:
        workingDir: /data/repo/Gradle/Gatling/Distributed
        resources:
          requests:
            cpu: 128m
            memory: 128Mi
      paused: true
      run:
        image: gradle
        shell: |
          ./gradlew gatlingRun
      artifacts:
        workingDir: /data/repo/Gradle/Gatling/Distributed/build/reports/
        paths:
        - '**/*'
status: {}

In the above file:

• The configuration specs specify the number of workers, virtual users, and duration of the test.
• The test source is a file from a GitHub repository. Refer to the distributed load test YAML spec file referenced in this specification.
• Resource restrictions for CPU and RAM and image details are provided.
• The test execution command, as well as the artifact settings for log collection, are provided.

Read our test workflow document to understand more about the test workflow specification.

Summary

This article highlights the importance of distributed load testing and presents Gatling as an effective tool to evaluate an application's ability to withstand real-world traffic demands. Without a doubt, we can say that load testing is essential for evaluating the application's resilience. Distributed load testing provides a more realistic, production-like environment, and tools such as Gatling simplify the process significantly.

Get started with Testkube today, or check out the Testkube documentation to learn more about running distributed tests in Testkube with other testing tools. If you find yourself struggling with anything, feel free to drop a note in our active Slack community, and someone will help you out.