Requirements and recommendations for the database
Database in production system
Database must be deployed as standalone solution outside of Allure Testops deployment. The performance of the database deployed in a pod with PVC or running in a container has worse performance of the database in case of high load generated by the automated tests. Such deployment is acceptable for demo purposes or for PoC stage, but for the production system with automated test results upload, the database must be deployed as standalone cluster with the requirements described further in this article.
Database storage hardware requirements
Database must use SSD as storage HW. Preferably enterprise grade SSDs. Allure Testops creates considerable workload towards the database when processing test results and querying the data and HDD as storage is not able to handle the workload. In case of HDD usage system performance will degrade with time (after 6-8 months of usage), and at some point in time database responses for the statistics will consume all available connections due to long response time and general system performance alongside with the user experience will suffer.
Issues with Allure Testops performance running on HDD cannot be resolved by support.
PostgreSQL version requirements
All versions of Allure Testops released after the 1st of January 2023 require PostgreSQL ver. 14.
After the 1st of March 2024, we'll discontinue the support of PostgreSQL 14 and PostgreSQL 15 will become the mandatory version.
Both statements mean, we do not perform any tests during the development and QA stages with any PostgreSQL versions except mandatory one, hence we cannot guarantee Allure Testops will be able to perform or start with PostgreSQL versions different from the mandatory one.
PostgreSQL parameters recommendations
Allure Testops heavily uses the databases and objects storage during the processing of the test results of automated tests and generation of the widgets in the projects dashboards, thus there are some recommendations based on our experience when working with highly loaded Allure Testops instances in our clients' environments.
random page cost
The setting of parameter random_page_cost
considerably affects the performance of PostgreSQL database and depends on the used storage's disks type.
- in case of SSD use
1.5
. - in case of really quick SSD like AWS gp2/gp3 with high IOPS use
1.2
. - in case of HDD - use default value
4.0
.- by all means avoid usage of HDD as DB storage.
- do not use the default value
4.0
with SSD.
work mem
work_mem
parameter depends on the RAM available for the database and max session allowed to the database.
New value of
work_mem
parameter will require restarting of the database.
The following formula is to be used to calculate the work_mem
:
work_mem
= db_available_ram x 0.2 / max_sessions_count,
where
max_sessions_count
= num_of_report_service_instances x connection_pool_size_per_instance
connection_pool_size_per_instance
is 10 by default.
work_mem calculation example
- Given 64GB RAM dedicated to your DB
- and you have 10 replicas of report service instances with connection pool size equal to 10
you need to set
work_mem
= 64000*0.2/100 = 128MB
effective io concurrency
effective_io_concurrency
is to be set to
64
in case of SSD1
in case of HDD (the default value)
AWS RDS
If you are using AWS RDS, make sure that IOPS is not limited.
For average/huge size customers, AWS RDS has at least 3 000 IOPS that is equal to 1 000 GB gp2 storage.
Creating the databases for uaa and report services
Allure Testops uses 2 databases - uaa for user management and report to store all the tests related data.
- You need to be authorized as DB admin
# switch to the postgres user on the database server
sudo su postgres
# connect to the database server
psql
Of course, you can use any other way to connect which is more comfortable for you.
- Creating uaa database
You may consider changing the at least password for the uaa user.
# create a new DB user for UAA service
CREATE USER uaa with encrypted password 'PaSSw0rd';
# create the database for uaa service
CREATE DATABASE uaa TEMPLATE template0 ENCODING 'utf8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
# connect to uaa databse
\c uaa
# grant all privileges to the user uaa on the uaa database
GRANT ALL PRIVILEGES ON database uaa to uaa;
# for PostgreSQL ver. 15 you need to grant all privileges on the public schema
GRANT ALL PRIVILEGES ON SCHEMA public TO uaa;
\q
exit
- Creating report database
You may consider changing the at least password for the report user.
# create a new DB user for report service
CREATE USER report with encrypted password 'PaSSw0rd';
# create the database for report service
CREATE DATABASE report TEMPLATE template0 ENCODING 'utf8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
# connect to report databse
\c report
# grant all privileges to the user report on the report database
GRANT ALL PRIVILEGES ON database report to report;
# for PostgreSQL ver. 15 you need to grant all privileges on the public schema
GRANT ALL PRIVILEGES ON SCHEMA public TO report;
\q
exit
Database schema
This feature is available starting from Allure Testops version 4.23.x and onwards.
In the vast majority of the cases, settings described below are not needed, and could lead to unpredictable results and inability of support if performed incorrectly. Please do not change the default schema unless your organisation rules dictate otherwise.
By default Allure Testops services uaa and report use the database schema public
. In case of your organisation rules do not allow the usage of public
scheme of the database, this behaviour can be overridden.
The database schema needs to be defined before the deployment and needs to remain the same during the system utilisation.
Using the alternative database schema
- Before deploying Allure Testops, add a database schema as defined by your policies
- we'll use
default
as an example. - Owner must be the user which is used in TestOps database connection configuration
- Database user must have all permissions for the database
- Database user should have all the privileges for the created schema
GRANT ALL ON SCHEMA default TO report;
GRANT ALL ON SCHEMA default TO uaa;
- we'll use
- Before deploying Allure Testops add the following configuration parameters to the default Allure Testops configuration
- to
report
serviceALLURE_DB_SCHEMA=default
- to
uaa
serviceALLURE_DB_SCHEMA=default
- to
You need to update values.yaml
file for both uaa's and report's sections env.open
as follows:
uaa:
<...>
env:
open:
ALLURE_DB_SCHEMA: default
<...>
report:
<...>
env:
open:
ALLURE_DB_SCHEMA: default
<...>
You need to update docker-compose.yml
file as follows.
services:
<...>
allure-uaa:
<...>
environment:
<...>
ALLURE_DB_SCHEMA: default
<...>
allure-report:
<...>
environment:
<...>
ALLURE_DB_SCHEMA: default
<...>
You need to update the configuration files:
- for report service
- /opt/allure-testops/report/conf/allure-report.conf
- for uaa service
- /opt/allure-testops/uaa/conf/allure-uaa.conf
For both files the following string needs to be added:
ALLURE_DB_SCHEMA=default