Allure TestOps : Как устроена система?

Главная проблема горы тестов : Где взять диски?

Масштабирование сервисов и баз данных

Оптимизации настроек и SQL-запросов

Радикальные оптимизации : кеширование и удаление

Рекомендации и скрипты : Как автоматизировать?

Allure TestOps : Как устроена система?

Главная проблема горы тестов : Где взять диски?

Масштабирование сервисов и баз данных

Оптимизации настроек и SQL-запросов

Радикальные оптимизации : кеширование и удаление

Рекомендации и скрипты : Как автоматизировать?

Allure TestOps : Как устроена сиыстема?

Главная проблема горы тестов : Где взять диски?

Масштабирование сервисов и баз данных

Оптимизации настроек и SQL-запросов

Радикальные оптимизации : кеширование и удаление

Рекомендации и скрипты : Как автоматизировать?

Allure TestOps : Как устроена сиыстема?

Главная проблема горы тестов : Где взять диски?

Масштабирование сервисов и баз данных

Оптимизации настроек и SQL-запросов

Радикальные оптимизации : кеширование и удаление

Рекомендации и скрипты : Как автоматизировать?

Храним 2 недели данные со статусом Broken и Failed

Храним 1 неделю данные со статусом Passed и Skipped

Данные это

• scenario

  • результаты выполнения шагов

• fixture

  • результаты выполнения общих шагов

• attachment

  • вложения, картинки

scenario:

• Remove scenario on Broken test results after 336 hours
• Remove scenario on Failed test results after 336 hours
• Remove scenario on Passed test results after 168 hours
• Remove scenario on Skipped test results after 168 hours

fixture:

• Remove fixture on Broken test results after 336 hours
• Remove fixture on Failed test results after 336 hours
• Remove fixture on Passed test results after 168 hours
• Remove fixture on Skipped test results after 168 hours

attachment:

• Remove attachment on Broken test results after 336 hours
• Remove attachment on Failed test results after 336 hours
• Remove attachment on Passed test results after 168 hours
• Remove attachment on Skipped test results after 168 hours

Выросло количество потоков:

rabbitConnectionFactorySharedExecutor -> taskExecutor

Утилизация CPU

на PostgreSQL = 100%

Отличаются на 200 (потребители и исполнители)

Отличаются на уже 2000 после масштабирования в 10 раз

Issue #102

Настройки по умолчанию заданы для 1-го сервиса

report:
  replicaCount: 1
  taskExecutorCorePoolSize: 200
  maxDBConn: 10
  maxConcurrency: 5
  maxS3Concurrency: 200

Если у нас больше реплик, то нужно пересчитать

report:
  replicaCount: 1
  taskExecutorCorePoolSize: 200

replicaCount больше, а taskExecutorCorePoolSize меньше

report:
  replicaCount: 10
  taskExecutorCorePoolSize: 20

Пусть будет 100 JDBC-подключений

report:
  replicaCount: 10
  taskExecutorCorePoolSize: 20
  maxDBConn: 100

Индекс

Несколько полей

В другом порядке

С фильтрацией по значению

browser == 'Chrome'

С фильтрацией по новым данным

id >= 9995

pg_stat_activity

️ данные за текущий момент

суммарные данные

pg_stat_statement

️ суммарные данные за долгое время

дельта данных

логи PostgreSQL

️ отсортированные по длительности

суммарные данные в отчете

pg_stat_activity

️ данные за текущий момент

суммарные данные

pg_stat_statement

️ суммарные данные за долгое время

дельта данных

логи PostgreSQL

️ отсортированные по длительности

суммарные данные в отчете

Ложный TOP-1 запрос

SELECT $2 
FROM ONLY "public"."launch" x 
WHERE "id" OPERATOR(pg_catalog.=) $1 
FOR KEY SHARE OF x
update "test_result" 
set 
    "scenario_key" = $1, 
    "last_modified_by" = $2, 
    "last_modified_date" = $3 
where "test_result"."id" in ($4)
update "test_result" 
set 
    "scenario_key" = $1, 
    "last_modified_by" = $2, 
    "last_modified_date" = $3 
where "test_result"."id" in ($4, $5)

Очень много запросов-дубликатов

select ... from test_result where id in ($1)

select ... from test_result where id in ($1, $2)

select ... from test_result where id in ($1, $2, 3)

select ... from test_result where id in ($1, $2, $3, $4)

select ... from test_result where id in ($1, $2, $3, $4, $5)

select ... from test_result where id in ($1, $2, $3, $4, $5, $6)

...

Можно схлопнуть дубликаты за счет регулярных выр

select query_key, query, queryid, 
    sum(total_exec_time) as time_sum
from (select
  regexp_replace(regexp_replace(regexp_replace(regexp_replace(
	regexp_replace(query, 
	' in [(][^)]+[)]', ' IN KEYS', 'g'),
	'[(]values [(].+[))]', '(VALUES (VAL))', 'g'),
	' values [(].+[)]', ' VALUES (VAL)', 'g'),
	'([0-9]+)', '1', 'g'),
	'(\n|\t|\s|\r|\v|\a|\b| )+', ' ', 'g')
	as "query_key", -- Template
	total_exec_time, query, queryid
  from pg_stat_statements
) foo
group by query_key, query, queryid
order by total_exec_time_sum desc, query_key, query

Можно схлопнуть дубликаты за счет регулярных выражений

select query_key, query, queryid, 
    sum(total_exec_time) as time_sum
from (select
  regexp_replace(regexp_replace(regexp_replace(regexp_replace(
	regexp_replace(query, 

	' in [(][^)]+[)]', ' IN KEYS', 'g'),
	'[(]values [(].+[))]', '(VALUES (VAL))', 'g'),
	' values [(].+[)]', ' VALUES (VAL)', 'g'),
	'([0-9]+)', '1', 'g'),
	'(\n|\t|\s|\r|\v|\a|\b| )+', ' ', 'g')

	as "query_key", -- Template
	total_exec_time, query, queryid
  from pg_stat_statements
) foo
group by query_key, query, queryid
order by total_exec_time_sum desc, query_key, query

Можно посчитать изменение метрики

Создать слепок:

	select * 
	into pg_stat_statements_2024_10_10
	from pg_stat_statements

Подождать и получить разницу

select "query_key", count(queryid) as "count", max(query) as "query",
	round(sum(total_exec_time)) as total_exec_time, sum(calls) as calls, 
	sum(total_exec_time)/sum(calls) as "mean",
	round(sum(shared_blks_hit)/sum(calls)) as "shared_blks_hit"
from ( select 
		regexp_replace(regexp_replace(regexp_replace(regexp_replace(regexp_replace(p.query,       
		' in [(][^)]+?[)]', ' IN KEYS', 'g'),
		'\(values \(.+?\)\)', '(VALUES (VAL))', 'g'),
		' values \(.+?\)', ' VALUES (VAL)', 'g'),
		'([0-9]+)', '1', 'g'),
		'(\n|\t|\s|\r|\v|\a|\b| )+', ' ', 'g') as "query_key",
		p.queryid, p.query,
		p.total_exec_time - prev.total_exec_time as total_exec_time,
		p.shared_blks_hit - prev.shared_blks_hit as shared_blks_hit,
		p.calls - prev.calls as calls,
		(p.total_exec_time - prev.total_exec_time) / (p.calls - prev.calls) as mean
	from  pg_stat_statements p join pg_stat_statements_2024_10_10 prev
		on (p.queryid = prev.queryid)
	where p.calls > prev.calls
) as stat
group by "query_key" order by total_exec_time desc

pg_stat_activity

️ данные за текущий момент

суммарные данные в VictoriaMetrics

pg_stat_statement

️ суммарные данные за долгое время

дельта данных

логи PostgreSQL

️ отсортированные по длительности

суммарные данные в отчете

Закешируем

http {
    proxy_cache_path /data/nginx/cache keys_zone=mycache:60m max_size=1g inactive=120m;
    limit_conn_zone $server_name zone=perserver:10m;
    upstream backend {server allure:443}
    server {
        listen 80;

        location /api/rs/analytic/3/statistic_trend {
            include shared.cache.conf;
        }
        location /api/rs/analytic/3/automation_chart {
            include shared.cache.conf;
        }
        location / {
            proxy_pass https://backend;
        }
    }
}

Закешируем

http {
    proxy_cache_path /data/nginx/cache keys_zone=mycache:60m max_size=1g inactive=120m;
    limit_conn_zone $server_name zone=perserver:10m;
    upstream backend {server allure:443}
    server {
        listen 80;

        location /api/rs/analytic/3/statistic_trend {
            include shared.cache.conf;
        }
        location /api/rs/analytic/3/automation_chart {
            include shared.cache.conf;
        }

        location / {
            proxy_pass https://backend;
        }
    }
}

Содержимое файле shared.cache.conf

# кешировать по URL-запроса
proxy_cache_key "$host$request_uri";

# на 60 минут для успешных ответов
proxy_cache_valid 200 302 60m;

proxy_cache_valid 404      1m;
proxy_cache_min_uses 1;
proxy_cache_methods GET;
proxy_cache_background_update on;
proxy_cache_revalidate on;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
proxy_ignore_headers Cache-Control;
proxy_pass https://backend;

Кешировать по URL-запроса

# кешировать по URL-запроса

proxy_cache_key "$host$request_uri";

# на 60 минут для успешных ответов
proxy_cache_valid 200 302 60m;

proxy_cache_valid 404      1m;
proxy_cache_methods GET;
proxy_cache_background_update on;
proxy_cache_revalidate on;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
proxy_ignore_headers Cache-Control;
proxy_pass https://backend;

Кешировать на 60 минут для успешных ответов с кодами 200 или 302

# кешировать по URL-запроса
proxy_cache_key "$host$request_uri";

# на 60 минут для успешных ответов

proxy_cache_valid 200 302 60m;

proxy_cache_valid 404      1m;
proxy_cache_min_uses 1;
proxy_cache_methods GET;
proxy_cache_background_update on;
proxy_cache_revalidate on;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
proxy_ignore_headers Cache-Control;
proxy_pass https://backend;