Производителност

Подробните доклади остават в хранилището в docs/perf/ (2026-09-baseline.md, 2026-09-load-test.md). Тази страница ги обобщава и показва как се измерва.

Тест за натоварване (септември 2026)

Една виртуална машина с 2 vCPU / 8 GB и PostgreSQL 16 (база данни от 2 GB, 70 000 други устройства, 5,6 млн. реда за софтуер), една реплика на бекенда (пул от 20, RLS включен), 5000 симулирани агента и k6. Симулираните агенти споделят процесорите, така че стойностите са консервативни.

Показател	Резултат
Регистриране на 5000 агента (по 80 програми всеки)	всички регистрирани за 59 s
Повторно свързване на 5000 агента след рестарт на бекенда	всички отново свързани за 12 s
Памет на WebSocket връзка	≈ 44 KB (19 KB heap + 25 KB стекове)
Записи на сигнали за активност (heartbeat) (5000 агента)	2 пакетни заявки в секунда, ≈ 20 ms време в базата данни на секунда
Внедряване към 1000 устройства, едновременни изпълнения 200	28 s; извикване за създаване 6,4 s; без взаимни блокировки (deadlocks)
API на портала при 50 заявки/s	p50 18 ms, p95 127 ms, p99 305 ms, 0 грешки

Какво поправи тестът: регистрирането вече не се сериализира върху реда на токена; секциите с инвентарни данни получават отпечатък (fingerprint) и непроменените се пропускат; едновременността при приемането на данни е ограничена до една четвърт от пула; сигналите за активност се групират в пакети; обработката на резултатите от внедряване е защитена от взаимни блокировки.

Базови стойности на API

Измерени върху тенант с 50 000 устройства. Цел: p95 за списъка с устройства под 200 ms. Постигната е за списъка и за всеки филтър освен филтъра по софтуер (p95 ≈ 540 ms) и прегледа на внедряване с условие за софтуер (p95 ≈ 890 ms), които минават през rmm_devices_with_software.

Измерване

1. Отделен Postgres с разширенията за статистика:

   docker run -d --name rmm-perf -p 55432:5432 -e POSTGRES_USER=rmm -e POSTGRES_PASSWORD=rmm -e POSTGRES_DB=rmm \
     postgres:16-alpine -c shared_preload_libraries=pg_stat_statements,auto_explain \
     -c auto_explain.log_min_duration=100ms -c auto_explain.log_analyze=on -c shared_buffers=1GB
   docker exec rmm-perf createdb -U rmm platform
   export RMM_DATABASE_URL=postgres://rmm:rmm@localhost:55432/rmm?sslmode=disable
   export PLATFORM_DATABASE_URL=postgres://rmm:rmm@localhost:55432/platform?sslmode=disable
   go run ./backend/cmd/server migrate up
   go run ./platform/backend/cmd/server migrate up

2. Заредете начални данни (около 8 минути при 2 vCPU):

   go run ./backend/cmd/seed --tenants 20 --devices 70000 --largest 50000 \
     --software-per-device 80 --jobs 500000 --audit 200000

   Зареждането на начални данни изисква и двете бази данни (RMM_DATABASE_URL и PLATFORM_DATABASE_URL или --database-url и --platform-database-url): всеки тенант се създава и като организация с Axis в Hub, с администратор на организацията admin@<slug>.seed.test (парола --password, по подразбиране seed-password-123), който е администратор на тенанта в Axis. Копието на Axis се записва по същото време, така че първата синхронизация не променя нищо.
3. Стартирайте Hub (make dev-platform) и сървъра с RMM_API_RATE_PER_SECOND=10000 и RMM_API_RATE_BURST=10000, след което:

   go run ./backend/cmd/apibench --api http://localhost:8080 --hub http://localhost:8090 \
     --email admin@<slug>.seed.test --tenant <tenant id> --n 40

   Инструментът влиза в Hub (--hub, по подразбиране http://localhost:8090), подновява при нужда своя продуктов токен с валидност пет минути и отпечатва p50/p95/max за всяка крайна точка като Markdown таблица.
4. Трафик от агенти и от портала: simagent --count 5000 … и k6 run -e BASE_URL=http://localhost:8080 -e HUB_URL=http://localhost:8090 -e EMAIL=… -e PASSWORD=… -e TENANT=<tenant id> loadtest/k6/portal.js. Скриптът за k6 влиза в Hub веднъж; всеки виртуален потребител издава собствен продуктов токен от тази сесия и го подновява преди изтичането му.

Бавни заявки

SELECT round(mean_exec_time::numeric, 1) AS mean_ms, calls,
       round(total_exec_time::numeric / 1000) AS total_s,
       left(regexp_replace(query, '\s+', ' ', 'g'), 200) AS query
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20;

За да видите план така, както го вижда приложението, първо изпълнете SET ROLE rmm_app; SET app.tenant_id = '<id>';. При RLS операторите, които не са leakproof (LIKE, ILIKE, @>), не могат да използват индекс, преди да бъде проверена политиката; използвайте функция със SECURITY DEFINER като rmm_devices_with_software.