|author||Thomas Draebing <email@example.com>||Tue Dec 10 11:33:15 2019 +0100|
|committer||Thomas Draebing <firstname.lastname@example.org>||Tue Dec 10 11:33:15 2019 +0100|
Move actions done before a test run out of the constructor The initial delay and cloning of projects were done, when a test client object was instantiated. This didn't seem like the proper place to do it and also led to a large constructor. Now these steps are performed in the prerun- method, which is called before the run()-method is called. Change-Id: Ic6b3766f4ee12e3c0d4d4633c97fb0c7177b143c
This project provides a tool to load test Gerrit by running a set of actions typically used by Gerrit users.
The test relies heavily on randomness. The script will for the duration of the tests loop through all possible actions that are defined. For each action it will calculate a random number between 0 and 1 and execute the action if the number is higher than a configured threshold. Thus, depending on the configuration, not all actions will be executed in each cycle of the loop, thereby simulating that users will not always do the same series of actions. By adjusting the probability thresholds different scenarios based on statistics can be simulated.
The python scripts are formatted using
black . The code style is further checked by
To install the tools, run:
pipenv install --dev
To lint the files, run:
pipenv run black $(find . -name '*.py') && pipenv run pylint $(find . -name '*.py')
Black will automatically format all python-files. Pylint, however, will not automatically fix issues in the code. Please fix the issues pylint is showing or in reasonable cases disable the respective rules in a reasonable scope.
The tool is meant to be run in a container. To build this container, run:
docker build -t gerrit/loadtester ./container
A configuration file in yaml-format can be used to configure the test run. The
config.sample.yaml-file gives an example-configuration.
The single configuration values are listed here:
|URL of the Gerrit test server|
|Gerrit user used for tests|
|Password of Gerrit user|
|Duration for which to run the tests|
|Whether to delay execution of a test run|
|Minimum initial delay in seconds|
|Maximum initial delay in seconds|
|Whether to create new projects during initialization|
|How many new projects to create during initialization|
|List of projects that the simulated user knows of from the beginning|
|Whether to pause between test cycles|
|Minimum time of pause|
|Maximum time of pause|
|Probability with which an action is performed in each cycle (|
The following actions can be performed by the tests:
|Test performs a clone of a project, that is assigned to the simulated user|
|Test creates a new project via REST|
|Test fetches a project, that is assigned to the simulated user and was already cloned|
|Test creates random commits in a cloned project and pushes them to |
|Test creates random commits in a cloned project and pushes them to the remote's |
|Queries changes via REST|
|Queries projects via REST|
|Reviews a change via REST|
To run an instance of the load tester. run:
docker run -it gerrit/loadtester \ --config $CONFIG_FILE \ --duration $TEST_DURATION \ --password $GERRIT_PWD \ --url $GERRIT_URL \ --user $GERRIT_USER
The options are:
None): Path to a config file (optional). The config file has to be present in the container, either by building it in or by mounting it. Parameters will overwrite configuration from file.
None): Duration, for which to run the tests in seconds (optional; if not set, test runs until stopped)
secret): Password of Gerrit user used for executing actions
--url: URL of Gerrit (REQUIRED; e.g.
admin): User to be used for executing actions
If the target Gerrit server is using the HTTPS-protocol, the load test requires a valid not self-signed CA. Certificates that are mounted to the
/var/loadtest/certs will be used to that perpose. This can be done like this:
docker run -it gerrit/loadtester \ -v <certificate dir>:/var/loadtest/certs
The docker containers may be used to run the load tests in Kubernetes to simulate multiple users (each instance acts as a single user). This project provides an example deployment yaml:
./kubernetes/load-tester/load-tester.*.yaml. To install the Kubernetes setup, adjust the configuration in the yaml-files.
./kubernetes/load-tester/load-tester.secret.yaml. The values have to be base64-encoded.
./kubernetes/load-tester/load-tester.configmap.yaml. The config-file structure is the same as described above.
Afterwards, create all resources on the cluster:
Kubectl apply ./kubernetes/load-tester/load-tester.secret.yaml Kubectl apply ./kubernetes/load-tester/load-tester.configmap.yaml Kubectl apply ./kubernetes/load-tester/load-tester.deployment.yaml
Further, an example deployment for a logging stack based on ElasticSearch, FluentBit and Kibana to collect the logs created by the load testing scripts is provided in
To install the EFK-stack, run:
helm install stable/elasticsearch \ -n elasticsearch \ -f ./kubernetes/efk/elasticsearch.yaml \ --namespace logging helm install stable/fluent-bit \ -n fluentbit \ -f ./kubernetes/efk/fluentbit.yaml \ --namespace logging helm install stable/kibana \ -f kubernetes/efk/kibana.yaml \ -n kibana \ --namespace logging