Eine frisch eingesetzte CloudTAK-Instanz mit Standardkonfiguration verarbeitet eine kleine Gruppe von ATAK-Geräten problemlos. Die Schwierigkeiten treten schrittweise auf: Die CoT-Ereigniszustellung beginnt zu verzögern, wenn der 80.–90. gleichzeitige Client verbunden wird, PostgreSQL-Verbindungspool-Fehler erscheinen bei etwa 150 Clients in den Protokollen, und bei 300+ Clients beginnt der Server, Ereignisse so aggressiv zu puffern, dass Feldeinheiten bemerken, dass ihr COP mehrere Minuten hinter der Realität zurückliegt. Dies ist keine grundlegende Einschränkung von CloudTAK — es ist die Folge des Ausführens einer operativen Arbeitslast mit Standardeinstellungen. Dieser Leitfaden behandelt den vollständigen Optimierungspfad: Leistungsbaseline festlegen, PostgreSQL optimieren, CoT-Datenverkehr begrenzen, WebSocket-Verbindungen verwalten, räumliche Filterung aktivieren und horizontal skalieren.
Leistungsbaseline: Was bedeuten 100, 500 und 1000 Clients bei Standardkonfiguration
Bevor Sie etwas optimieren, messen Sie den aktuellen Zustand. Der CloudTAK-Admin-Metrik-Endpunkt bietet den direktesten Einblick in den Server-Zustand. Wichtige Felder: cot_queue_depth, db_pool_waiting und event_loop_lag_ms. Bei Standardkonfiguration (2 vCPU / 4 GB, DB_POOL_MAX=10): 100 Clients — CPU 28%, p50-Latenz 210 ms, 0 DB-Fehler; 500 Clients — CPU 94%, p50-Latenz 3.800 ms, 47 DB-Fehler/Min; 1.000 Clients — CPU gesättigt, p50-Latenz >30.000 ms.
PostgreSQL-Optimierung: PgBouncer, shared_buffers, work_mem und Autovacuum
PostgreSQL ist der dominierende Engpass in den meisten unzureichend konfigurierten CloudTAK-Deployments. Fügen Sie PgBouncer im Transaktions-Pooling-Modus zwischen CloudTAK und PostgreSQL hinzu — diese eine Änderung eliminiert typischerweise alle Verbindungspool-Erschöpfungsfehler und reduziert den PostgreSQL-Speicherverbrauch bei 500+ Clients um 60–80%. Stellen Sie shared_buffers auf 25% des gesamten Server-RAMs ein, work_mem = 8MB und verschärfen Sie Autovacuum-Schwellenwerte (autovacuum_vacuum_scale_factor = 0.02) für die tracks-Tabelle.
CoT-Ratenbegrenzung: Pro-Client-Limits, Stale-Time-Tuning und Track-Bereinigung
Konfigurieren Sie einen Standard-Wert von 5 Ereignissen/s für Infanterie-Geräte und Überschreibungen für UAV-Feeds (20–50 Ereignisse/s) über die CloudTAK-Admin-API. Setzen Sie COT_STALE_SECONDS=300, damit Tracks, die seit mehr als 5 Minuten nicht aktualisiert wurden, aus dem Live-Bild entfernt werden.
WebSocket-Verbindungsverwaltung: Max. Verbindungen, Heartbeat-Tuning, Bereinigung toter Verbindungen
Erhöhen Sie CLOUDTAK_WS_PING_INTERVAL von 30 auf 60 Sekunden, um die Heartbeat-CPU-Last zu halbieren. Setzen Sie CLOUDTAK_WS_PONG_TIMEOUT=15 für die zuverlässige Bereinigung toter Verbindungen. Erhöhen Sie das OS-Dateideskriptoren-Limit auf 65.536 in der Docker-Compose-Konfiguration.
Horizontale Skalierung: mehrere CloudTAK-Instanzen, Load Balancer, Session-Affinität
Wenn die Node.js-Event-Loop einer einzelnen CloudTAK-Instanz CPU-gesättigt ist, ist horizontale Skalierung der nächste Schritt. CloudTAK v2.x unterstützt Multi-Instanz-Deployments über eine gemeinsame PostgreSQL-Datenbank und Redis Pub/Sub. Konfigurieren Sie HAProxy mit IP-Hash-basierter Session-Affinität — da TAK-Clients persistente TCP-Verbindungen aufrechterhalten, muss der Load Balancer jeden Client konsistent an dieselbe CloudTAK-Instanz weiterleiten.
Feed-Optimierung: räumliche Filterung und auflösungsbasierte Filterung
Räumliche Filterung schränkt ein, welche Tracks jeder Client erhält, auf die innerhalb seines Interessensbereichs (AOI). Ohne räumliche Filterung wird jedes CoT-Ereignis an jeden verbundenen Client gesendet. In einem 500-Client-Szenario mit gemischten Infanterie- und UAV-Feeds reduzierte die Aktivierung der räumlichen Filterung mit einem AOI-Radius von 50 km die ausgehende Bandbreite um 65% und den WebSocket-Frame-CPU um 40%.
Profiling-Tools: Admin-API-Metriken, pg_stat_statements und Linux perf
Verwenden Sie drei Diagnose-Ebenen: (1) CloudTAK-Admin-API-Metrik-Endpunkt; (2) PostgreSQL pg_stat_statements für die teuersten Abfragen; (3) Linux perf oder Flamegraph für CPU-Profiling des CloudTAK-Node.js-Prozesses.
Benchmark-Ergebnisse: vor und nach der Optimierung für das 500-Client-Szenario
In unserem 500-Client-Benchmark-Szenario (450 Infanterie-Clients mit 0,05 Hz + 50 UAV-Feeds mit 5 Hz): Mediane CoT-Latenz sank von 3.800 ms auf 310 ms; p99-Latenz von 18.200 ms auf 890 ms; DB-Verbindungsfehler von 47/Min auf 0; Server-CPU von 94% auf 38%; ausgehende Bandbreite von 340 Mbit/s auf 118 Mbit/s nach Aktivierung der räumlichen Filterung.