Äskettäin käyttöönotettu CloudTAK-instanssi oletuskonfiguraatiolla käsittelee pienen ATAK-laitteiden ryhmän ongelmitta. Ongelmat ilmenevät vähitellen: CoT-tapahtumien toimitus alkaa viivästyä, kun 80.–90. samanaikainen asiakas muodostaa yhteyden, PostgreSQL-yhteysaltaan tyhjentymisvirheet alkavat näkyä lokeissa noin 150 asiakkaan kohdalla, ja 300+ asiakkaan kohdalla palvelin alkaa jonottaa tapahtumia niin aggressiivisesti, että kenttäyksiköt huomaavat COP:nsa olevan useita minuutteja todellisuudesta jäljessä. Tämä ei ole CloudTAK:n perustavanlaatuinen rajoitus — se on seuraus operatiivisen mittakaavan työkuorman ajamisesta oletusasetuksilla. Tämä opas kattaa koko optimointipolun: suorituskyvyn peruslinjan määrittäminen, PostgreSQL:n optimointi, CoT-liikenteen rajoittaminen, WebSocket-yhteyksien hallinta, spatiaalisen suodatuksen käyttöönotto ja horisontaalinen skaalaus.
Suorituskyvyn peruslinja: mitä 100, 500 ja 1000 asiakasta tarkoittaa oletuskonfiguraatiolla
Ennen minkäänlaista virittämistä mittaa nykyinen tila. CloudTAK:n järjestelmänvalvojan metriikat tarjoavat suorimman näkymän palvelimen kuntoon. Keskeisiä kenttiä: cot_queue_depth, db_pool_waiting ja event_loop_lag_ms. Oletuskonfiguraatiolla (2 vCPU / 4 Gt, DB_POOL_MAX=10): 100 asiakasta — suoritin 28%, p50-viive 210 ms, 0 tietokantavirhettä; 500 asiakasta — suoritin 94%, p50-viive 3 800 ms, 47 tietokantavirhettä/min; 1 000 asiakasta — suoritin kyllästynyt, p50-viive >30 000 ms.
PostgreSQL-optimointi: PgBouncer, shared_buffers, work_mem ja autovacuum
PostgreSQL on hallitseva pullonkaula useimmissa riittämättömästi konfiguroiduissa CloudTAK-käyttöönotoissa. Lisää PgBouncer transaktioallastustilassa CloudTAK:n ja PostgreSQL:n väliin — tämä yksi muutos yleensä eliminoi kaikki yhteysaltaan tyhjentymisvirheet ja vähentää PostgreSQL:n muistinkäyttöä 60–80% 500+ asiakkaan kanssa. Aseta shared_buffers 25%:iin palvelimen kokonais-RAM:sta, work_mem = 8MB ja kiristä autovacuum-kynnykset (autovacuum_vacuum_scale_factor = 0.02) tracks-taulukolle.
CoT-nopeuden rajoittaminen: asiakaskohtaiset rajat, vanhentumisajan virittäminen ja raitojen karsinta
Määritä oletusarvo 5 tapahtumaa/s jalkaväen laitteille ja ylikirjoitukset UAV-syötteille (20–50 tapahtumaa/s) CloudTAK:n järjestelmänvalvojan API:n kautta. Aseta COT_STALE_SECONDS=300, jotta yli 5 minuuttia ilman päivitystä olevat raidat poistetaan live-kuvasta.
WebSocket-yhteyksien hallinta: maks. yhteydet, heartbeat-virittäminen, kuolleiden yhteyksien siivous
Kasvata CLOUDTAK_WS_PING_INTERVAL 30:stä 60 sekuntiin heartbeat-suorittimenkuorman puolittamiseksi. Aseta CLOUDTAK_WS_PONG_TIMEOUT=15 kuolleiden yhteyksien luotettavaan siivoukseen. Kasvata käyttöjärjestelmän tiedostokuvarajausta 65 536:een Docker Compose -konfiguraatiossa.
Horisontaalinen skaalaus: useita CloudTAK-instansseja, kuormantasain, istuntoaffiniteetti
Kun yhden CloudTAK-instanssin Node.js-tapahtumasilmukka on suorittimeltaan kyllästynyt, horisontaalinen skaalaus on seuraava askel. CloudTAK v2.x tukee moni-instanssikäyttöönottoja jaetun PostgreSQL-tietokannan ja Redis pub/sub:n kautta. Määritä HAProxy IP-hash-pohjaisella istuntoaffiniteetilla — koska TAK-asiakkaat ylläpitävät pysyviä TCP-yhteyksiä, kuormantasaimen on ohjattava jokainen asiakas jatkuvasti samaan CloudTAK-instanssiin.
Syötteen optimointi: spatiaalinen suodatus ja resoluutiopohjainen suodatus
Spatiaalinen suodatus rajoittaa, mitä raitoja kukin asiakas vastaanottaa, vain niihin hänen kiinnostusalueellaan (AOI). Ilman spatiaalista suodatusta jokainen CoT-tapahtuma lähetetään kaikille yhdistetyille asiakkaille. 500 asiakkaan skenaariossa sekoitettujen jalkaväen ja UAV-syötteiden kanssa spatiaalisen suodatuksen käyttöönotto 50 km:n AOI-säteellä vähensi lähtevää kaistanleveyttä 65% ja WebSocket-kehyksen käsittelyn suorittimenkäyttöä 40%.
Profilointityökalut: järjestelmänvalvojan API-metriikat, pg_stat_statements ja Linux perf
Käytä kolmea diagnostiikkakerrosta: (1) CloudTAK:n järjestelmänvalvojan API-metriikat; (2) PostgreSQL pg_stat_statements kalleimmille kyselyille; (3) Linux perf tai flamegraph CloudTAK Node.js -prosessin suorittimen profilointiin.
Benchmark-tulokset: ennen ja jälkeen virittämisen 500 asiakkaan skenaariossa
500 asiakkaan benchmark-skenaariossa (450 jalkaväen asiakasta 0,05 Hz:llä + 50 UAV-syötettä 5 Hz:llä): mediaani CoT-viive laski 3 800 ms:sta 310 ms:iin; p99-viive 18 200 ms:sta 890 ms:iin; tietokantayhteysvirheet 47/min:sta 0:aan; palvelimen suorittimenkäyttö 94%:sta 38%:iin; lähtevä kaistanleveys 340 Mbps:sta 118 Mbps:iin spatiaalisen suodatuksen käyttöönoton jälkeen.