Gain insights into Gatling fundamentals, delve into advanced scripting, simulate network conditions with puppeteer and lighthouse, and set up Jenkins CI for scalable performance testing automation.

performance.tar.gz

Puppeteer

Gatling-1

Java

shell

Lighthouse

gatling-spa-run-framework

gatling-spa-run-framework-copy

Gatling

gatling-local-server

gatling-local-server-live

Almost every company in the world needs to test its scalability and performance of their products or applications.

In this course, you will learn the fundamentals of Gatling, an open-source performance testing tool that is in great demand in the software industry. You will start by learning the basics of performance testing including scalability testing and stress testing.

You will then move on to more advanced concepts such as writing Gatling scripts, understanding web page performance and simulating network throttling using puppeteer and lighthouse tools.

Lastly, you will learn to set up Continuous Integration (CI) using Jenkins for Gatling which will be useful for running tests remotely. By the end of this course, you will have some new great skills for your resume.

Performance Test Automation 101: Gatling, Lighthouse, & Jenkins

# Running the simulation against multiple hosts

In this simulation example, we will learn how to distribute the load equally against multiple target URLs or endpoints.

Gatling, out-of-the-box, provides this feature, assuming we have set an _HTTP global configuration_, which will be used by all the requests.

Consider the following simulation for a demonstration:


import io.gatling.core.Predef._
import io.gatling.http.Predef._

import scala.concurrent.duration._

class SampleSimulation extends Simulation {

  val protocols = http
    .disableCaching // disable caching of response
    .disableWarmUp // disable initial warmup before sending actual requests
    .baseUrls("http://localhost:8080", "http://localhost:8080") // setting base URLs
    .contentTypeHeader("application/json") // setting content-type header
    .acceptHeader("application/json") // setting accept header

  val scn = scenario("sample scenario")
    .exec(http("fetch all the users")
      .get("/api/users") // making a GET request to fetch all users
      .check(
        status.is(200), // assert http status code is 200
        jsonPath("$.data[*].id").exists 
        // extract list of ids from response and check if they exist
      )
    )

  // creating an user injection profile to execute the scenario at a
  // constant rate of 2 users per second over a duration of 5 seconds
  // with http global configurations as declared.
  setUp(scn.inject(constantUsersPerSec(2) during (5 seconds))).protocols(protocols)
}

Most customer-facing URLs will have load balancers virtually behind them that distribute the load to the multiple instances of the application deployed on different hosts. This load balancing of requests to multiple hosts is what we will delegate to Gatling. 

This simulation is no different than the other simulations we have seen in previous lessons. 
The only difference is that in the 
*HTTP global configurations*, we set an array of base URLs, as shown at *line 11*, to allow Gatling to distribute the requests equally to the base URLs.

```
.baseUrls("http://localhost:8080", "http://localhost:8080")
```

The relative URL mentioned at *line 17* is prepended with the URLs mentioned as base URLs in an orderly sequence for every user request.
```
.get("/api/users")
```

> **Note:** Please note we are using the same URL twice. When using real applications, please use the IPs or hostnames of each for the instances.

# Running the simulation from multiple clients

In order to generate a large load, we can run the simulation from different client machines.

To achieve the same with the open-source version of Gatling, we have some prerequisites as mentioned below:

* Create *n* instances of remote machines. 
* Public keys must be exchanged between each of the remote machines and the machine where we will trigger the script using `ssh-copy-id` to avoid password prompts. In our case, we are considering our local machine as the source to trigger the script.
* All remote machines have the same user `ubuntu`.
* Gatling binaries need to be downloaded and extracted to the following location:

   ```
   GATLING_HOME=/gatling/gatling-charts-highcharts-3.3.1
   ```
   >Please remember to change the script if the location is changed to something else.
Ensure the location has write permissions for the user `ubuntu`.

   The latest version of Gatling binaries can be downloaded [here](https://gatling.io/open-source/start-testing/).

The below bash script is pretty much self-explanatory. Just to give an overview, we perform the following steps:

* Copy the simulation scripts present at `$GATLING_HOME/user-files/simulations` on the local machine to each of the remote machines from where we are going to run the scripts.
* Trigger the simulation on each of the remote machines.
* Copy the simulation reports present at `$GATLING_HOME/results/` from each of the remote machines to the local machine.
* Aggregate all the collected reports from each of the remote machines.   


Most customer-facing URLs will have load balancers virtually behind them that distribute the load to the multiple instances of the application deployed on different hosts. This load balancing of requests to multiple hosts is what we will delegate to Gatling. 

This simulation is no different than the other simulations we have seen in previous lessons. 
The only difference is that in the 
*HTTP global configurations*, we set an array of base URLs, as shown at *line 11*, to allow Gatling to distribute the requests equally to the base URLs.

```
.baseUrls("http://localhost:8080", "http://localhost:8080")
```

The relative URL mentioned at *line 17* is prepended with the URLs mentioned as base URLs in an orderly sequence for every user request.
```
.get("/api/users")
```

> **Note:** Please note we are using the same URL twice. When using real applications, please use the IPs or hostnames of each for the instances.

# Running the simulation from multiple clients

In order to generate a large load, we can run the simulation from different client machines.

To achieve the same with the open-source version of Gatling, we have some prerequisites as mentioned below:

* Create *n* instances of remote machines. 
* Public keys must be exchanged between each of the remote machines and the machine where we will trigger the script using `ssh-copy-id` to avoid password prompts. In our case, we are considering our local machine as the source to trigger the script.
* All remote machines have the same user `ubuntu`.
* Gatling binaries need to be downloaded and extracted to the following location:

   ```
   GATLING_HOME=/gatling/gatling-charts-highcharts-3.3.1
   ```
   >Please remember to change the script if the location is changed to something else.
Ensure the location has write permissions for the user `ubuntu`.

   The latest version of Gatling binaries can be downloaded [here](https://gatling.io/open-source/start-testing/).

The below bash script is pretty much self-explanatory. Just to give an overview, we perform the following steps:

* Copy the simulation scripts present at `＄GATLING_HOME/user-files/simulations` on the local machine to each of the remote machines from where we are going to run the scripts.
* Trigger the simulation on each of the remote machines.
* Copy the simulation reports present at `＄GATLING_HOME/results/` from each of the remote machines to the local machine.
* Aggregate all the collected reports from each of the remote machines.   


Learn how to run the simulation against a service deployed on multiple hosts and the simulation script from multiple client machines.

Introduction

Basics of Performance Testing

Gatling: Load and Stress Testing Tool

Gatling: Script Features

Examples: Simulations Using Gatling

Web Page Performance

Network Throttling

Download Custom Gatling Test Framework

Gatling with Jenkins

Conclusion

Example 3 - Distributed Load Test Simulation

Running the simulation against multiple hosts