Щойно розгорнутий екземпляр CloudTAK із типовою конфігурацією без проблем обробляє невелику команду пристроїв ATAK. Проблеми з'являються поступово: доставка CoT-подій починає запізнюватися, коли підключається 80–90-й паралельний клієнт, помилки вичерпання пулу з'єднань PostgreSQL з'являються у журналах приблизно при 150 клієнтах, а при 300+ клієнтах сервер починає ставити події в чергу настільки агресивно, що польові підрозділи помічають відставання COP на кілька хвилин. Це не є фундаментальним обмеженням CloudTAK — це наслідок запуску робочого навантаження операційного масштабу на налаштуваннях за замовчуванням. Цей посібник охоплює повний шлях оптимізації: встановлення базового рівня продуктивності, оптимізацію PostgreSQL, обмеження CoT-трафіку, управління WebSocket-з'єднаннями, увімкнення просторової фільтрації та горизонтальне масштабування.
Базовий рівень продуктивності: що означає 100, 500 та 1000 клієнтів при типовій конфігурації
Перш ніж щось налаштовувати, виміряйте поточний стан системи. Кінцева точка метрик адміністратора CloudTAK забезпечує найбільш прямий вигляд стану сервера:
watch -n5 'curl -s -H "Authorization: Bearer $ADMIN_TOKEN" \
https://tak.yourdomain.com:8443/api/admin/metrics | jq .'При типовій конфігурації (2 vCPU / 4 ГБ, DB_POOL_MAX=10) для трьох рівнів навантаження: 100 клієнтів — CPU 28%, затримка p50 210 мс, помилок БД 0; 500 клієнтів — CPU 94%, затримка p50 3 800 мс, 47 помилок БД/хв; 1000 клієнтів — CPU насичений 100%, затримка p50 >30 000 мс, 300+ помилок БД/хв. Рядок 500 клієнтів є операційною точкою перелому для більшості розгортань у сфері оборони — саме тут налаштування забезпечують найбільше абсолютне покращення.
Налаштування PostgreSQL: PgBouncer, shared_buffers, work_mem та autovacuum
PostgreSQL є домінуючим вузьким місцем у більшості недостатньо налаштованих розгортань CloudTAK. Два окремі проблеми поєднуються: вичерпання з'єднань (забагато паралельних з'єднань застосунку для моделі PostgreSQL «один процес на з'єднання») та повільні запити (відсутні індекси, погано налаштовані параметри пам'яті та відставання autovacuum на таблиці треків з великим записом).
Пулінг з'єднань PgBouncer
Додайте PgBouncer як проміжний сервіс у ваш стек Docker Compose. Використовуйте режим пулінгу транзакцій — це дозволяє великій кількості короткочасних з'єднань CloudTAK спільно використовувати невелику кількість реальних бекенд-процесів PostgreSQL. Оновіть DATABASE_URL CloudTAK, щоб він вказував на PgBouncer. Ця одна зміна зазвичай усуває всі помилки вичерпання пулу з'єднань і зменшує використання пам'яті PostgreSQL на 60–80% при 500+ клієнтах.
Параметри пам'яті PostgreSQL
Змонтуйте користувацький postgresql.conf у контейнер PostgreSQL: встановіть shared_buffers на 25% від загального обсягу RAM сервера (наприклад, 2 ГБ для 8 ГБ сервера), effective_cache_size на 75% RAM, work_mem = 8MB та maintenance_work_mem = 256MB. Зменшіть max_connections до 60 — пулінг з'єднань через PgBouncer означає, що PostgreSQL більше не потребує сотень бекенд-процесів.
Autovacuum для робочих навантажень з великою кількістю записів
Таблиця tracks CloudTAK отримує безперервні операції INSERT та UPDATE та масові DELETE від завдання очищення збереження. Налаштування autovacuum за замовчуванням спрацьовують при 20% коефіцієнті «мертвих» кортежів — встановіть autovacuum_vacuum_scale_factor = 0.02 та autovacuum_analyze_scale_factor = 0.01 для цієї таблиці через ALTER TABLE tracks SET (...). Також переконайтеся, що просторовий індекс PostGIS GIST та складений індекс (uid, timestamp DESC) існують у таблиці треків.
Обмеження швидкості CoT: на клієнт, налаштування часу застарівання та прунінг треків
Другий за впливом важіль налаштування — контроль обсягу CoT-подій, які сервер приймає та зберігає. Три параметри працюють разом: обмеження швидкості вхідного потоку на клієнт, поріг часу застарівання (як довго трек залишається в живій картині після останнього оновлення) та вікно збереження (як довго історичні треки зберігаються в базі даних).
Налаштуйте значення за замовчуванням 5 подій/с для піхотних пристроїв та перевизначення для UAV-каналів (20–50 подій/с) через API адміністратора CloudTAK. Встановіть COT_STALE_SECONDS=300, щоб треки, які не оновлювалися більше 5 хвилин, видалялися з живої картини — це запобігає накопиченню тисяч «примарних» треків від відключених активів.
Управління WebSocket-з'єднаннями: максимальна кількість з'єднань, налаштування heartbeat, очищення мертвих з'єднань
Кожен підключений клієнт ATAK або WinTAK утримує постійне WebSocket-з'єднання з CloudTAK. При 500+ одночасних з'єднаннях параметри heartbeat за замовчуванням створюють відчутне навантаження на CPU. Збільшіть CLOUDTAK_WS_PING_INTERVAL з 30 до 60 секунд, щоб вдвічі зменшити частоту heartbeat. Встановіть CLOUDTAK_WS_PONG_TIMEOUT=15 для надійного очищення мертвих з'єднань. Також збільшіть ліміт файлових дескрипторів ОС до 65 536 у конфігурації Docker Compose (ulimits.nofile).
Горизонтальне масштабування: кілька екземплярів CloudTAK, балансувальник навантаження, спорідненість сеансів
Коли event loop Node.js одного екземпляра CloudTAK насичений CPU, горизонтальне масштабування є наступним кроком. CloudTAK v2.x підтримує розгортання з кількома екземплярами через спільну базу даних PostgreSQL та Redis pub/sub для розподілу подій між екземплярами. Налаштуйте HAProxy із спорідненістю сеансів за IP-хешем — оскільки клієнти TAK підтримують постійні TCP-з'єднання, балансувальник навантаження повинен маршрутизувати кожного клієнта стабільно до одного екземпляра CloudTAK.
Оптимізація каналів: просторова фільтрація та фільтрація за роздільністю
Найбільше зменшення пропускної здатності досягається за допомогою просторової фільтрації — кожному клієнту доставляються лише треки в межах його зони інтересів (AOI). Без просторової фільтрації кожна CoT-подія транслюється всім підключеним клієнтам, тому навантаження масштабується як O(клієнти × події). У сценарії з 500 клієнтами зі змішаними піхотними та UAV-каналами, ввімкнення просторової фільтрації з радіусом AOI 50 км зменшило вихідну пропускну здатність на 65% та CPU обробки WebSocket-кадрів на 40%.
Інструменти профілювання: метрики API адміністратора, pg_stat_statements та Linux perf
Налаштування без профілювання — це вгадування. Використовуйте три рівні діагностики: (1) кінцева точка метрик API адміністратора CloudTAK (GET /api/admin/metrics) — постійно висока глибина черги вказує на вузьке місце запису в БД; (2) PostgreSQL pg_stat_statements — визначте 10 найдорожчих запитів за загальним часом виконання; (3) Linux perf або flamegraph для профілювання CPU процесу Node.js CloudTAK.
Результати бенчмарків: до та після налаштування для сценарію з 500 клієнтами
У нашому сценарії з 500 клієнтами (450 піхотних клієнтів з частотою 0,05 Гц + 50 UAV-каналів з частотою 5 Гц) результати до/після були такими: медіанна затримка CoT знизилася з 3 800 мс до 310 мс; 99-й перцентиль затримки — з 18 200 мс до 890 мс; помилки з'єднання з БД знизилися з 47 на хвилину до 0; використання CPU сервером — з 94% до 38%; вихідна пропускна здатність — з 340 Мбіт/с до 118 Мбіт/с. Застосований повний набір налаштувань: PgBouncer у режимі транзакцій, PostgreSQL shared_buffers=2 ГБ, просторова фільтрація з AOI 50 км, WebSocket ping-інтервал 60 с, два екземпляри CloudTAK за HAProxy із sticky-сеансами.