Påvirker SWEAR ydeevnen i XProtect?

Kort svar

SWEAR påvirker dit XProtect-miljø minimalt.

SWEAR's hashing af sikkerhedsvideo ændrer ikke nogen af dine optagelser og påvirker kun processorer og hukommelsesforbrug på XProtect-servere minimalt. Båndbreddeforbruget i SWEAR-systemet skaber omkring en halv megabyte hashes pr. time pr. kamera og sender derefter disse hashes til en blockchain-understøttet hovedbog.

Forklaring

Hvad SWEAR gør under drift

SWEAR integrerer med Milestone XProtect for at tilføje autenticitetsbeskyttelse under normal videodrift ved at:

Læse kamerastreamdata fra optagelsesworkflowet
Generere deterministiske kryptografiske hash-poster fra videodata
Sætte disse hash-poster i kø og uploade dem via SWEAR API

SWEAR gør ikke følgende:

Genindkoder eller transkoder kameravideo
Erstatter Milestone-tjenester til optagelse eller afspilning
Eksporterer rå video til SWEAR-infrastruktur

Derfor er den praktiske effekt på VMS-adfærd typisk ubetydelig i den daglige drift.

Hvorfor påvirkningen typisk er lav

Driftsomkostningen er koncentreret omkring hashing samt kø- og uploadbehandling og ikke omkring flytning af fulde videolaster uden for recorderen. Hash-poster er små, udgående trafik er let, og behandling skalerer primært med den samlede beskyttede bitrate (antal kameraer x bitrate pr. kamera).

I stabil drift betyder det typisk:

Lavt til moderat CPU-forbrug i forhold til tilgængelige serverkerner
Beskedent forbrug af arbejdshukommelse
Lille kontinuerlig udgående netværkstrafik kun til upload af hash-poster
Forudsigelig diskaktivitet fra lokal, holdbar kølagring (indsæt/slet-livscyklus)

Hvordan ydeevnen skalerer

Baseret på antagelser i runtime-modellering (ikke direkte benchmarking i felten) er den omtrentlige stabile adfærd:

Resource	10 cameras	50 cameras	200 cameras	Primary driver
CPU (steady state)	~1-3% of 1 core	~5-15% of 1 core	~0.2-0.6 core	Hashing + frame/NAL processing
Working set (RAM)	~90-130 MB	~120-180 MB	~200-350 MB	Service base + per-camera workers + buffers
Network out	~1 KB/s	~5 KB/s	~20 KB/s	Hash-record API POSTs only
Disk write activity	~3-8 KB/s	~15-40 KB/s	~50-150 KB/s	Local durable queue lifecycle

Disse værdier går op eller ned med kameraets bitrate og profil (for eksempel øger 4K-streams med høj bitrate arbejdsbelastningen proportionalt).

Hvornår du kan mærke midlertidig påvirkning

Kortvarige spidser opstår oftest i undtagelsesscenarier især:

Backfill-/indhentningsperioder: Efter genstart af tjenesten eller nedetid behandler SWEAR historisk backlog hurtigere for at komme tilbage til live-kanten
API-/netværksafbrydelser: Ventende poster ophobes. Når forbindelsen vender tilbage stiger uploadaktiviteten mens backlog drænes
Uddybende logning aktiveret i lange perioder: Logvækst kan blive driftsmæssigt betydelig på diske med begrænset kapacitet

Disse forhold er generelt driftsmæssige og kan gendannes. De er ikke normal stabil adfærd.

Praktisk vejledning til stabil ydeevne

For at holde SWEAR-ydelsen forudsigelig i Milestone-miljøer:

Beskyt kun de tilsigtede kamerakanaler
Overvåg køtrenden og uploadtilstanden i SWEAR-statusvisningen
Hold netværksveje til SWEAR API-endpoints stabile
Brug normale produktionslogniveauer medmindre du aktivt fejlsøger
Planlæg kapacitet efter samlet beskyttet bitrate og ikke kun antal kameraer

Fejlfindingssignaler

Brug disse mønstre til at skelne mellem sund drift og pres:

Sund: Både genererede og uploadede poster stiger, og køen forbliver stabil
Backlog opbygges: Genererede poster stiger hurtigere end uploadede poster, og køen vokser over tid
Uploadpres/fejl: Tællere for fejl/sene uploads stiger gentagne gange, og køen tømmes ikke

Hvis backlog eller fejl fortsætter, skal du validere tjenestetilstand, API-tilgængelighed og log-/diskforhold. Kontakt derefter support med aktuelle statustællere og observationsvindue.