Beeinträchtigt SWEAR die Leistung von XProtect?

Kurz gesagt

Die Auswirkungen von SWEAR auf Ihre XProtect-Umgebung sind minimal.

Das Hashing von Sicherheitsvideos durch SWEAR verändert keine Ihrer Aufzeichnungen und hat nur minimale Auswirkungen auf die Prozessor- und Speichernutzung der XProtect-Server. Die Bandbreitennutzung des SWEAR-Systems erzeugt pro Kamera und Videostunde etwa ein halbes Megabyte an Hashes und sendet diese Hashes anschließend an ein Blockchain-gestütztes Konto.

Erläuterung

Funktionsweise von SWEAR zur Laufzeit

SWEAR wird in Milestone XProtect integriert, um während des normalen Videobetriebs einen Authentizitätsschutz hinzuzufügen. Dazu führt der Service folgende Schritte aus:

Lesen von Kamerastream-Daten aus dem Aufzeichnungsablauf
Erzeugen plangesteurter kryptografischer Hash-Datensätze aus Videodaten
Diese Hash-Datensätze werden über die SWEAR API in die Warteschlange gestellt und hochgeladen

SWEAR führt folgende Aktionen nicht aus:

Erneutes Codieren oder Transcodieren von Kameravideos
Ersetzen der Aufzeichnungs- oder Wiedergabeservice von Milestone
Exportieren unverarbeiteter Videos in SWEAR's Infrastruktur

Daher sind die praktischen Auswirkungen auf das Verhalten des VMS im täglichen Betrieb in der Regel geringfügig.

Warum die Auswirkungen normalerweise gering sind

Der Laufzeitaufwand konzentriert sich vorallem auf das Hashing sowie die Bearbeitung der Warteschlange und der Uploads, und nicht auf das Verschieben vollständiger Videonutzdaten aus dem Rekorder. Hash-Datensätze sind klein, der ausgehende Datenverkehr ist gering und die Verarbeitung skaliert hauptsächlich mit der gesamten geschützten Bitrate (Anzahl der Kameras x Bitrate pro Kamera).

Im stabilen Betriebszustand bedeutet dies normalerweise:

Geringe bis moderate CPU-Nutzung im Verhältnis zu den verfügbaren Server-Core
Moderater Arbeitsspeicherbedarf
Geringer kontinuierlicher ausgehender Netzwerkverkehr ausschließlich für Uploads von Hash-Datensätzen
Vorhersehbare Datenträgeraktivität durch die lokale Persistenz der Warteschlange (Lebenszyklus aus Einfügen und Löschen)

Skalierung der Leistung

Basierend auf Annahmen aus Laufzeitmodellen (nicht im direkten Leistungsvergleich-Bereich) ergibt sich im stabilen Betriebszustand ungefähr folgendes Verhalten:

Ressource	10 Kameras	50 Kameras	200 Kameras	Hauptfaktor
CPU (stabiler Betriebszustand)	~1-3% eines Core	~5-15% eines Core	~0.2-0.6 Core	Hashing + Frame-/NAL-Verarbeitung
Arbeitssatz (RAM)	~90-130 MB	~120-180 MB	~200-350 MB	Basis Service + Worker pro Kamera + Puffer
Ausgehender Netzwerkverkehr	~1 KB/s	~5 KB/s	~20 KB/s	Nur API POSTs für Hash-Datensätze
Schreibaktivität auf dem Datenträger	~3-8 KB/s	~15-40 KB/s	~50-150 KB/s	Lebenszyklus der lokalen persistenten Warteschlange

Diese Werte steigen oder sinken abhängig von der Bitrate und dem Profil der Kamera. (zum Beispiel: 4K Streams mit höherer Bitrate erhöhen die Arbeitslast proportional).

Wann könnte man vorübergehende Auswirkungen bemerken

Kurzzeitige Lastspitzen treten am wahrscheinlichsten in Ausnahmeszenarien auf, insbesondere bei:

Nachverarbeitungs-/Aufholphasen: Nach einem Neustart oder einer Ausfallzeit verarbeitet SWEAR historische Rückstände schneller, um wieder den aktuellen Stand zu erreichen
API-/Netzwerkunterbrechungen: Ausstehende Datensätze sammeln sich an; sobald die Verbindung wiederhergestellt ist, steigt die Upload-Aktivität, während der Rückstand abgearbeitet wird
Über längere Zeit aktivierter ausführlicher Protokollierung: Das Wachstum der Protokolldateien kann auf Datenträgern mit begrenzter Kapazität betrieblich relevant werden

Diese Bedingungen sind in der Regel betriebsbedingt und behebbar und entsprechen nicht dem normalen stabilen Betriebszustand.

Praktische Empfehlungen für eine stabile Leistung

So sorgen Sie für eine vorhersehbare Leistung von SWEAR in Milestone-Umgebungen:

Schützen Sie nur die vorgesehenen Kamerakanäle
Überwachen Sie den Verlauf der Warteschlange und den Uploadstatus in der Statusansicht von SWEAR
Sorgen Sie für zuverlässige Netzwerkpfade zu den Endpunkten der SWEAR API
Verwenden Sie die normalen Protokollierungsstufen für den Produktivbetrieb, sofern Sie nicht gerade eine Fehlerbehebung durchführen
Planen Sie die Kapazität anhand der gesamten geschützten Bitrate und nicht allein anhand der Anzahl der Kameras

Hinweise zur Fehlerbehebung

Interpretieren Sie anhand der folgenden Muster, ob das System fehlerfrei arbeitet oder unter Druck steht:

Fehlerfrei: Die Anzahl der erzeugten und hochgeladenen Datensätze steigt, die Warteschlange bleibt stabil
Rückstand entsteht: Die Anzahl der erzeugten Datensätze steigt schneller als die der hochgeladenen Datensätze, die Warteschlange wächst mit der Zeit
Uploadbelastung/-fehler: Die Zahl der fehlgeschlagenen/verspäteten Vorgänge steigt wiederholt, die Warteschlange wird nicht abgearbeitet

Falls Rückstände oder Fehler fortbestehen, überprüfen Sie den Dienststatus, die Erreichbarkeit der API sowie die Protokollierungs- und Datenträgerbedingungen. Wenden Sie sich anschließend mit den aktuellen Statuszählern und dem Beobachtungszeitraum an den Support.