TestOps logo
Try TestOps

Requirements and recommendations for the database

This section described recommendations applicable for Allure TestOps version 5.

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

As of March 1, 2024, Allure TestOps only supports PostgreSQL database version 15 or higher.

This means that 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 SSD
  • 1 in case of HDD (the default value)

shared_buffers

We recommend to set shared_buffers to at least 50% of available RAM. For better performance, you can set it up to 75% of available RAM — however, make sure to monitor the state of RAM and adjust the parameter towards lower values (e.g., back to 50%) if there is a high competition for RAM resources.

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 database

Allure TestOps uses a single database for both user management and storing all the tests related data.

  1. 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.

  2. Creating the database

    You may consider changing at least the password for the testops user.

For sake of this example we use testops as the database user name, and as name of the database.

# create a new DB user
CREATE USER testops with encrypted password 'PaSSw0rd';
# create the database
CREATE DATABASE testops TEMPLATE template0 ENCODING 'utf8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
# connect to the databse
# grant all privileges to the user testops on the testops database
GRANT ALL PRIVILEGES ON database testops to testops;
\c testops
# grant all privileges on the public schema
GRANT ALL PRIVILEGES ON SCHEMA public TO testops;
\q

Usage of alternative 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 service uses 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

  1. Before deploying Allure TestOps, add a database schema as defined by your policies
    1. We'll use default as an example.
    2. Owner must be the user which is used in TestOps database connection configuration
    3. Database user must have all permissions for the database
    4. Database user should have all the privileges for the created schema
      1. GRANT ALL ON SCHEMA default TO testops;
  2. Before deploying Allure TestOps add the following configuration parameters to the default Allure TestOps configuration
    1. to testops service
      1. ALLURE_DB_SCHEMA=default

You need to update values.yaml file for env.open section as follows:

  env:
    open:
      ALLURE_DB_SCHEMA: default
<...>

You need to update docker-compose.yml file as follows.


services:
  testops:
    <...>
    environment:
    <...>
     ALLURE_DB_SCHEMA: default
    <...>

You need to update the configuration files:

  • for report service
    • /opt/testops/conf/testops.conf

The following string needs to be added:

ALLURE_DB_SCHEMA=default

Separating connection pools

This is only relevant for Kubernetes deployments.

By default, Allure TestOps uses a single connection pool for all types of database queries. Its size is determined by the datasources.mainDatasource.appMaxDBConnection setting.

In a high load production environment, you may want not just to increase the total number of connections, but to make sure that longer operations do not take the resources from the faster and more important ones. This can be done by enabling separate uploader pools and analytics pools. The analytics pool may also be configured to use an alternate datasource.

  • The uploader pool, if enabled, will be used when uploading new test results to Allure TestOps.

    To enable the uploader pool:

    1. Set datasources.uploaderDatasource.enabled to true.
    2. Set datasources.uploaderDatasource.appMaxDBConnection to the maximum number of uploader connections.

  • The analytics pool, if enabled, will be used for some of the read-only aggregated data queries. It is a common practice to use a separate database for analytics, with replication configured between the two databases.

    To enable the analytics pool:

    1. Set datasources.analyticsDatasource.enabled to true.
    2. Set datasources.analyticsDatasource.appMaxDBConnection to the maximum number of analytics connections.
    3. Set the PostgreSQL credentials in datasources.analyticsDatasource.* similarly to how you set the main database settings.
© Qameta Software Inc. All rights reserved.