Une instance CloudTAK fraîchement déployée avec une configuration par défaut gère sans difficulté un petit groupe d'appareils ATAK. Les problèmes apparaissent progressivement : la livraison des événements CoT commence à se dégrader lorsque le 80e ou 90e client simultané se connecte, des erreurs d'épuisement du pool de connexions PostgreSQL apparaissent dans les journaux autour de 150 clients, et à 300+ clients le serveur commence à mettre en file d'attente les événements si agressivement que les unités de terrain remarquent que leur COP est en retard de plusieurs minutes sur la réalité. Il ne s'agit pas d'une limitation fondamentale de CloudTAK — c'est la conséquence d'une charge de travail opérationnelle exécutée avec des paramètres par défaut. Ce guide couvre le chemin complet d'optimisation : établir une baseline de performance, optimiser PostgreSQL, limiter le trafic CoT, gérer les connexions WebSocket, activer le filtrage spatial et faire évoluer horizontalement.
Baseline de performance : ce que représentent 100, 500 et 1000 clients avec la configuration par défaut
Avant d'optimiser quoi que ce soit, mesurez l'état actuel. Le point de terminaison des métriques administrateur CloudTAK offre la vue la plus directe de la santé du serveur. Champs clés : cot_queue_depth, db_pool_waiting et event_loop_lag_ms. Avec la configuration par défaut : 100 clients — CPU 28%, latence p50 210 ms, 0 erreur BD ; 500 clients — CPU 94%, latence p50 3 800 ms, 47 erreurs BD/min ; 1 000 clients — CPU saturé, latence p50 >30 000 ms.
Optimisation PostgreSQL : PgBouncer, shared_buffers, work_mem et autovacuum
PostgreSQL est le goulot d'étranglement dominant dans la plupart des déploiements CloudTAK insuffisamment configurés. Ajoutez PgBouncer en mode de pooling de transactions entre CloudTAK et PostgreSQL — cette seule modification élimine généralement toutes les erreurs d'épuisement du pool de connexions et réduit l'utilisation de la mémoire PostgreSQL de 60 à 80 % avec 500+ clients. Définissez shared_buffers à 25 % de la RAM totale du serveur, work_mem = 8MB et resserrez les seuils d'autovacuum (autovacuum_vacuum_scale_factor = 0.02) pour la table tracks.
Limitation du débit CoT : limites par client, réglage de la temporisation et élagage des pistes
Configurez une valeur par défaut de 5 événements/s pour les appareils d'infanterie et des remplacements pour les flux UAV (20–50 événements/s) via l'API administrateur CloudTAK. Définissez COT_STALE_SECONDS=300 afin que les pistes non mises à jour depuis plus de 5 minutes soient supprimées de l'image en direct.
Gestion des connexions WebSocket : connexions max, réglage du heartbeat, nettoyage des connexions mortes
Augmentez CLOUDTAK_WS_PING_INTERVAL de 30 à 60 secondes pour réduire de moitié la charge CPU du heartbeat. Définissez CLOUDTAK_WS_PONG_TIMEOUT=15 pour un nettoyage fiable des connexions mortes. Augmentez la limite des descripteurs de fichiers OS à 65 536 dans la configuration Docker Compose.
Mise à l'échelle horizontale : plusieurs instances CloudTAK, équilibreur de charge, affinité de session
Lorsque la boucle d'événements Node.js d'une seule instance CloudTAK est saturée en CPU, la mise à l'échelle horizontale est l'étape suivante. CloudTAK v2.x prend en charge les déploiements multi-instances via une base de données PostgreSQL partagée et Redis pub/sub. Configurez HAProxy avec une affinité de session basée sur le hachage IP — étant donné que les clients TAK maintiennent des connexions TCP persistantes, l'équilibreur de charge doit toujours diriger chaque client vers la même instance CloudTAK.
Optimisation des flux : filtrage spatial et filtrage par résolution
Le filtrage spatial limite les pistes que chaque client reçoit à celles dans sa zone d'intérêt (AOI). Sans filtrage spatial, chaque événement CoT est diffusé à chaque client connecté. Dans un scénario avec 500 clients et des flux mixtes d'infanterie et UAV, l'activation du filtrage spatial avec un rayon AOI de 50 km a réduit la bande passante sortante de 65 % et le CPU de traitement des trames WebSocket de 40 %.
Outils de profilage : métriques de l'API administrateur, pg_stat_statements et Linux perf
Utilisez trois couches de diagnostic : (1) le point de terminaison des métriques de l'API administrateur CloudTAK ; (2) PostgreSQL pg_stat_statements pour les requêtes les plus coûteuses ; (3) Linux perf ou flamegraph pour le profilage CPU du processus Node.js CloudTAK.
Résultats des benchmarks : avant et après optimisation pour le scénario à 500 clients
Dans notre scénario de benchmark à 500 clients (450 clients d'infanterie à 0,05 Hz + 50 flux UAV à 5 Hz) : la latence médiane CoT est passée de 3 800 ms à 310 ms ; la latence p99 de 18 200 ms à 890 ms ; les erreurs de connexion BD de 47/min à 0 ; l'utilisation CPU du serveur de 94 % à 38 % ; la bande passante sortante de 340 Mbps à 118 Mbps après activation du filtrage spatial.