Een vers geïmplementeerde CloudTAK-instantie met standaardconfiguratie verwerkt een kleine groep ATAK-apparaten zonder problemen. De problemen verschijnen geleidelijk: CoT-eventlevering begint te vertragen wanneer de 80e–90e gelijktijdige client verbinding maakt, PostgreSQL-verbindingspool-uitputtingsfouten verschijnen in de logboeken rond 150 clients, en bij 300+ clients begint de server events zo agressief te bufferen dat veldeenheden merken dat hun COP enkele minuten achterloopt op de werkelijkheid. Dit is geen fundamentele beperking van CloudTAK — het is een gevolg van het uitvoeren van een operationele werklast met standaardinstellingen. Deze gids behandelt het volledige optimalisatiepad: een prestatiebasislijn vaststellen, PostgreSQL optimaliseren, CoT-verkeer beperken, WebSocket-verbindingen beheren, ruimtelijke filtering inschakelen en horizontaal schalen.
Prestatiebasislijn: wat 100, 500 en 1000 clients betekenen met standaardconfiguratie
Voordat u iets optimaliseert, meet u de huidige toestand. Het CloudTAK admin metrics endpoint biedt het meest directe inzicht in de servergezondheid. Sleutelvelden: cot_queue_depth, db_pool_waiting en event_loop_lag_ms. Met standaardconfiguratie: 100 clients — CPU 28%, p50-latentie 210 ms, 0 DB-fouten; 500 clients — CPU 94%, p50-latentie 3 800 ms, 47 DB-fouten/min; 1 000 clients — CPU verzadigd, p50-latentie >30 000 ms.
PostgreSQL-optimalisatie: PgBouncer, shared_buffers, work_mem en autovacuum
PostgreSQL is het dominante knelpunt in de meeste onvoldoende geconfigureerde CloudTAK-implementaties. Voeg PgBouncer toe in transactie-poolingmodus tussen CloudTAK en PostgreSQL — deze ene wijziging elimineert doorgaans alle verbindingspool-uitputtingsfouten en vermindert het PostgreSQL-geheugengebruik met 60–80% bij 500+ clients. Stel shared_buffers in op 25% van het totale server-RAM, work_mem = 8MB en versnel autovacuum-drempels (autovacuum_vacuum_scale_factor = 0.02) voor de tracks-tabel.
CoT-snelheidsbeperking: limieten per client, verouderde tijdafstemming en trackverwijdering
Configureer een standaardwaarde van 5 events/s voor infanterie-apparaten en overschrijvingen voor UAV-feeds (20–50 events/s) via de CloudTAK admin API. Stel COT_STALE_SECONDS=300 in zodat tracks die langer dan 5 minuten niet zijn bijgewerkt, worden verwijderd uit het live beeld.
WebSocket-verbindingsbeheer: max. verbindingen, heartbeat-afstemming, dode verbindingen opschonen
Verhoog CLOUDTAK_WS_PING_INTERVAL van 30 naar 60 seconden om de heartbeat-CPU-last te halveren. Stel CLOUDTAK_WS_PONG_TIMEOUT=15 in voor betrouwbare opschoning van dode verbindingen. Verhoog de OS-bestandsdescriptorlimiet naar 65 536 in de Docker Compose-configuratie.
Horizontale schaling: meerdere CloudTAK-instanties, load balancer, sessie-affiniteit
Wanneer de Node.js-event loop van één CloudTAK-instantie CPU-verzadigd is, is horizontale schaling de volgende stap. CloudTAK v2.x ondersteunt multi-instantie-implementaties via een gedeelde PostgreSQL-database en Redis pub/sub. Configureer HAProxy met op IP-hash gebaseerde sessie-affiniteit — omdat TAK-clients persistente TCP-verbindingen onderhouden, moet de load balancer elke client consistent naar dezelfde CloudTAK-instantie routeren.
Feedoptimalisatie: ruimtelijke filtering en op resolutie gebaseerde filtering
Ruimtelijke filtering beperkt welke tracks elke client ontvangt tot die binnen zijn aandachtsgebied (AOI). Zonder ruimtelijke filtering wordt elk CoT-event naar elke verbonden client uitgezonden. In een 500-client-scenario met gemengde infanterie- en UAV-feeds verminderde het inschakelen van ruimtelijke filtering met een AOI-straal van 50 km de uitgaande bandbreedte met 65% en de WebSocket-frame-CPU met 40%.
Profileertools: admin API-metrieken, pg_stat_statements en Linux perf
Gebruik drie diagnostische lagen: (1) het CloudTAK admin API metrics endpoint; (2) PostgreSQL pg_stat_statements voor de duurste query's; (3) Linux perf of flamegraph voor CPU-profilering van het CloudTAK Node.js-proces.
Benchmarkresultaten: voor en na afstemming voor het 500-client-scenario
In ons 500-client-benchmarkscenario (450 infanterie-clients op 0,05 Hz + 50 UAV-feeds op 5 Hz): mediane CoT-latentie daalde van 3 800 ms naar 310 ms; p99-latentie van 18 200 ms naar 890 ms; DB-verbindingsfouten van 47/min naar 0; server-CPU van 94% naar 38%; uitgaande bandbreedte van 340 Mbps naar 118 Mbps na het inschakelen van ruimtelijke filtering.