Świeżo wdrożona instancja CloudTAK z domyślną konfiguracją obsługuje małą grupę urządzeń ATAK bez problemu. Problemy pojawiają się stopniowo: dostarczanie zdarzeń CoT zaczyna się opóźniać, gdy łączy się 80–90 równoczesny klient, błędy wyczerpania puli połączeń PostgreSQL pojawiają się w dziennikach około 150 klientów, a przy 300+ klientach serwer kolejkuje zdarzenia tak agresywnie, że jednostki terenowe zauważają, że ich COP jest o kilka minut za rzeczywistością. Nie jest to fundamentalne ograniczenie CloudTAK — to konsekwencja uruchamiania obciążenia w skali operacyjnej na domyślnych ustawieniach. Ten przewodnik obejmuje pełną ścieżkę strojenia: ustalenie bazowego poziomu wydajności, optymalizację PostgreSQL, ograniczanie ruchu CoT, zarządzanie połączeniami WebSocket, włączanie filtrowania przestrzennego i skalowanie poziome.
Bazowy poziom wydajności: co oznacza 100, 500 i 1000 klientów przy domyślnej konfiguracji
Przed jakimkolwiek strojeniem zmierz aktualny stan. Punkt końcowy metryk administratora CloudTAK zapewnia najbardziej bezpośredni wgląd w kondycję serwera. Kluczowe pola: cot_queue_depth, db_pool_waiting, cot_latency_p99_ms oraz event_loop_lag_ms. Przy domyślnej konfiguracji (2 vCPU / 4 GB, DB_POOL_MAX=10): 100 klientów — CPU 28%, opóźnienie p50 210 ms, 0 błędów BD; 500 klientów — CPU 94%, opóźnienie p50 3 800 ms, 47 błędów BD/min; 1000 klientów — CPU nasycony, opóźnienie p50 >30 000 ms.
Strojenie PostgreSQL: PgBouncer, shared_buffers, work_mem i autovacuum
PostgreSQL jest dominującym wąskim gardłem w większości niedostatecznie skonfigurowanych wdrożeń CloudTAK. Dwa oddzielne problemy łączą się: wyczerpanie połączeń (zbyt wiele równoległych połączeń aplikacji dla modelu PostgreSQL „jeden proces na połączenie") oraz wolne zapytania. Dodaj PgBouncer w trybie puli transakcji między CloudTAK a PostgreSQL — ta jedna zmiana zazwyczaj eliminuje wszystkie błędy wyczerpania puli i zmniejsza zużycie pamięci PostgreSQL o 60–80% przy 500+ klientach. Ustaw shared_buffers na 25% całkowitej pamięci RAM serwera, work_mem = 8MB oraz zaostrz progi autovacuum (autovacuum_vacuum_scale_factor = 0.02) dla tabeli tracks.
Ograniczanie szybkości CoT: limity na klienta, strojenie czasu przestarzałości i przycinanie śladów
Skonfiguruj domyślną wartość 5 zdarzeń/s dla urządzeń piechoty i nadpisania dla kanałów UAV (20–50 zdarzeń/s) przez API administratora CloudTAK. Ustaw COT_STALE_SECONDS=300, aby ślady, które nie były aktualizowane przez ponad 5 minut, były usuwane z aktualnego obrazu — zapobiega to gromadzeniu tysięcy „widmowych" śladów od rozłączonych zasobów.
Zarządzanie połączeniami WebSocket: maks. połączeń, strojenie heartbeat, czyszczenie martwych połączeń
Zwiększ CLOUDTAK_WS_PING_INTERVAL z 30 do 60 sekund, aby zmniejszyć o połowę obciążenie CPU heartbeatem. Ustaw CLOUDTAK_WS_PONG_TIMEOUT=15 dla niezawodnego czyszczenia martwych połączeń. Zwiększ limit deskryptorów plików systemu operacyjnego do 65 536 w konfiguracji Docker Compose.
Skalowanie poziome: wiele instancji CloudTAK, load balancer, koligacja sesji
Gdy pętla zdarzeń Node.js jednej instancji CloudTAK jest nasycona CPU, skalowanie poziome jest następnym krokiem. CloudTAK v2.x obsługuje wdrożenia wieloinstancyjne przez wspólną bazę danych PostgreSQL i Redis pub/sub do dystrybucji zdarzeń między instancjami. Skonfiguruj HAProxy z koligacją sesji opartą na hashu IP — ponieważ klienci TAK utrzymują trwałe połączenia TCP, load balancer musi stale kierować każdego klienta do tej samej instancji CloudTAK.
Optymalizacja kanałów: filtrowanie przestrzenne i filtrowanie według rozdzielczości
Filtrowanie przestrzenne ogranicza, jakie ślady otrzymuje każdy klient, tylko do tych w jego obszarze zainteresowania (AOI). Bez filtrowania przestrzennego każde zdarzenie CoT jest rozgłaszane do każdego podłączonego klienta. W scenariuszu z 500 klientami i mieszanymi kanałami piechoty i UAV, włączenie filtrowania przestrzennego z promieniem AOI 50 km zmniejszyło przepustowość wyjściową o 65% i CPU przetwarzania ramek WebSocket o 40%.
Narzędzia profilowania: metryki API administratora, pg_stat_statements i Linux perf
Użyj trzech warstw diagnostycznych: (1) punkt końcowy metryk API administratora CloudTAK — stale wysoka głębokość kolejki wskazuje na wąskie gardło zapisu BD; (2) PostgreSQL pg_stat_statements — identyfikuj 10 najkosztowniejszych zapytań według łącznego czasu wykonania; (3) Linux perf lub flamegraph do profilowania CPU procesu Node.js CloudTAK.
Wyniki benchmarków: przed i po strojeniu dla scenariusza 500 klientów
W naszym scenariuszu z 500 klientami (450 klientów piechoty z częstotliwością 0,05 Hz + 50 kanałów UAV z częstotliwością 5 Hz) wyniki przed/po były następujące: medianowe opóźnienie CoT spadło z 3 800 ms do 310 ms; percentyl 99. opóźnienia — z 18 200 ms do 890 ms; błędy połączenia z BD — z 47 na minutę do 0; wykorzystanie CPU serwera — z 94% do 38%; przepustowość wyjściowa — z 340 Mbps do 118 Mbps po włączeniu filtrowania przestrzennego.