SWEAR a-t-il un impact sur les performances de XProtect ?
En bref
L’impact de SWEAR sur votre environnement XProtect est minime.
Le hachage des vidéos de sécurité par SWEAR ne modifie ni n’altère aucun de vos enregistrements et n’a qu’un impact minime sur les processeurs et l’utilisation de la mémoire des serveurs XProtect. Le système SWEAR utilise environ un demi-mégaoctet de bande passante pour les hachages par heure de vidéo et par caméra, puis envoie ces hachages à un registre fondé sur la blockchain.
Explication
Ce que fait SWEAR pendant son fonctionnement
SWEAR s’intègre à Milestone XProtect pour ajouter une protection de l’authenticité pendant les opérations vidéo normales en effectuant les actions suivantes :
- Lecture des données des flux de caméra issues du processus d’enregistrement
- Génération d’enregistrements de hachage cryptographique déterministes à partir des données vidéo
- Mise en file d’attente et téléversement de ces enregistrements de hachage via l’API SWEAR
SWEAR ne réalise aucune des actions suivantes :
- Réencoder ou transcoder les vidéos des caméras
- Remplacer les services d’enregistrement ou de lecture de Milestone
- Exporter des vidéos brutes vers l’infrastructure SWEAR
C’est pourquoi l’effet concret sur le comportement du VMS est généralement négligeable dans les opérations quotidiennes.
Pourquoi l’impact est généralement faible
Le coût d’exécution se concentre sur le hachage ainsi que sur le traitement de la file d’attente et des téléversements, et non sur le transfert de charges vidéo complètes hors de l’enregistreur. Les enregistrements de hachage sont petits, le trafic sortant est léger et le traitement évolue principalement en fonction du débit protégé total (nombre de caméras × débit par caméra).
En régime stable, cela signifie généralement :
- Utilisation faible à modérée du processeur par rapport aux cœurs de serveur disponibles
- Empreinte modeste de la mémoire de travail
- Faible trafic réseau sortant continu, réservé au téléversement des enregistrements de hachage
- Activité disque prévisible due à la persistance de la file d’attente locale (cycle d’insertion et de suppression)
Évolution des performances
Selon les hypothèses de modélisation de l’exécution (et non des tests comparatifs directs sur le terrain), le comportement approximatif en régime stable est le suivant :
| Ressource | 10 caméras | 50 caméras | 200 caméras | Facteur principal |
|---|---|---|---|---|
| Processeur (régime stable) | ~1-3% de 1 cœur | ~5-15% de 1 cœur | ~0.2-0.6 cœur | Hachage + traitement des trames/NAL |
| Ensemble de travail (RAM) | ~90-130 MB | ~120-180 MB | ~200-350 MB | Service de base + processus par caméra + mémoires tampons |
| Trafic réseau sortant | ~1 KB/s | ~5 KB/s | ~20 KB/s | Uniquement les requêtes POST de l’API pour les enregistrements de hachage |
| Activité d’écriture sur le disque | ~3-8 KB/s | ~15-40 KB/s | ~50-150 KB/s | Cycle de vie de la file d’attente locale durable |
Ces valeurs augmentent ou diminuent selon le débit et le profil des caméras (par exemple, les flux 4K à débit plus élevé augmentent proportionnellement la charge de travail).
Situations dans lesquelles un impact temporaire peut être perceptible
Des pics de courte durée sont plus susceptibles de se produire dans des situations exceptionnelles, notamment :
- Périodes de rattrapage : après un redémarrage ou une interruption du service, SWEAR traite plus rapidement l’historique accumulé afin de revenir au flux en direct
- Interruptions de l’API ou du réseau : les enregistrements en attente s’accumulent ; une fois la connectivité rétablie, l’activité de téléversement augmente pendant le traitement de l’arriéré
- Journalisation détaillée activée pendant de longues périodes : la croissance des journaux peut devenir importante sur le plan opérationnel lorsque l’espace disque est limité
Ces conditions sont généralement de nature opérationnelle et réversibles ; elles ne correspondent pas au comportement normal en régime stable.
Recommandations pratiques pour assurer des performances stables
Pour maintenir des performances prévisibles de SWEAR dans les environnements Milestone :
- Protégez uniquement les canaux de caméra prévus
- Surveillez l’évolution de la file d’attente et l’état des téléversements dans la vue d’état de SWEAR
- Veillez à la fiabilité des chemins réseau vers les points de terminaison de l’API SWEAR
- Utilisez les niveaux de journalisation habituels en production, sauf lors d’un dépannage actif
- Planifiez la capacité en fonction du débit protégé total, et non du seul nombre de caméras
Indices de dépannage
Utilisez les schémas suivants pour distinguer un fonctionnement sain d’une charge excessive :
- Fonctionnement sain : le nombre d’enregistrements générés et téléversés augmente et la file d’attente reste stable
- Formation d’un arriéré : le nombre d’enregistrements générés augmente plus rapidement que le nombre d’enregistrements téléversés et la file d’attente s’allonge au fil du temps
- Saturation ou échec des téléversements : les compteurs d’échecs ou de retards augmentent de façon répétée et la file d’attente ne se résorbe pas
Si l’arriéré ou les échecs persistent, vérifiez l’état du service, l’accessibilité de l’API ainsi que les conditions de journalisation et de stockage, puis contactez l’assistance en lui communiquant les compteurs d’état actuels et la période d’observation.