This document provides a description of a Gerrit load test scenario implemented using the Gatling framework.

Similar scenarios have been successfully used to compare performance of different Gerrit versions or study the Gerrit response under different load profiles.

What is Gatling?

Gatling is a load testing tool which provides out of the box support for the HTTP protocol. Documentation on how to write an HTTP load test can be found here.

However, in the scenario we are proposing, we are leveraging the Gatling Git extension to run tests at Git protocol level.

Gatling is written in Scala, but the abstraction provided by the Gatling DSL makes the scenarios implementation easy even without any Scala knowledge. The Stress your Gerrit with Gatling blog post has more introductory information.

Examples of scenarios can be found in the e2e-tests directory. The files in that directory should be formatted using the mainstream Scala plugin for IntelliJ. The latter is not mandatory but preferred for sbt and Scala IDE purposes in this project.

How to build the tests

An sbt-based installation of Scala is required.

The scalaVersion used by sbt once installed is defined in the build.sbt file. That specific version of Scala is automatically used by sbt while building:

sbt compile

The following warning, if present when executing sbt commands, can be removed by creating the related credentials file locally. Dummy values for user and password in that file can be used initially.

[warn] Credentials file ~/.sbt/sonatype_credentials does not exist

Every sbt command can include an optional log level argument. Below, [info] logs are no longer shown:

sbt --warn compile

How to build using Docker

docker build . -t e2e-tests

How to set-up

SSH keys

If you are running SSH commands, the private keys of the users used for testing need to go in /tmp/ssh-keys. The keys need to be generated this way (JSch won’t validate them otherwise):

mkdir /tmp/ssh-keys
ssh-keygen -m PEM -t rsa -C "test@mail.com" -f /tmp/ssh-keys/id_rsa

The public key in /tmp/ssh-keys/id_rsa.pub has to be added to the test user(s) SSH Keys in Gerrit. Now, the host from which the latter runs may need public key scanning to become known. This applies to the local user that runs the forthcoming sbt testing commands. An example assuming localhost follows:

ssh-keyscan -t rsa -p 29418 localhost > ~/.ssh/known_hosts

Input file

The CloneUsingBothProtocols scenario is fed with the data coming from the src/test/resources/data/CloneUsingBothProtocols.json file. Such a file contains the commands and repository used during the load test. That file currently looks like below. This scenario serves as a simple example with no actual load in it. It can be used to test or validate the local setup. More complex scenarios can be further developed, under the com.google.gerrit.scenarios package.

[
  {
    "url": "ssh://admin@localhost:29418/loadtest-repo",
    "cmd": "clone"
  },
  {
    "url": "http://localhost:8080/loadtest-repo",
    "cmd": "clone"
  }
]

Valid commands are:

  • fetch

  • pull

  • push

  • clone

The example above assumes that the loadtest-repo project exists in the Gerrit under test.

How to run tests

Run all tests:

sbt "gatling:test"

Run a single test:

sbt "gatling:testOnly com.google.gerrit.scenarios.CloneUsingBothProtocols"

Generate the last report:

sbt "gatling:lastReport"

The src/test/resources/logback.xml file configures Gatling’s logging level.

How to run using Docker

docker run -it e2e-tests -s com.google.gerrit.scenarios.CloneUsingBothProtocols

Part of Gerrit Code Review

[scala]: