blob: c8c2ab888c6dfe98e54f24ff2e377034731f0767 [file] [log] [blame]
= Gerrit Code Review - End to end load tests
This document provides a description of a Gerrit load test scenario implemented using the
link:[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
However, in the scenario we are proposing, we are leveraging the
link:[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
link:[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
link:[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 link:[sbt-based installation] of
link:[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
link:[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
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
mkdir /tmp/ssh-keys
ssh-keygen -m PEM -t rsa -C "" -f /tmp/ssh-keys/id_rsa
The public key in `/tmp/ssh-keys/` 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 `` 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"
Generate the last report:
sbt "gatling:lastReport"
The `src/test/resources/logback.xml` file
link:[configures] Gatling's logging level.
=== How to run using Docker
docker run -it e2e-tests -s
Part of link:index.html[Gerrit Code Review]