Does SWEAR impact XProtect’s performance?
In Short
SWEAR’s impact on your XProtect environment is minimal.
SWEAR’s hashing of security videos does not modify or alter any of your recordings and has minimal impact on XProtect servers’ processors and memory usage. Bandwidth usage of the SWEAR system creates about a half of megabyte of hashes for each hour of video per camera and then sends those hashes to blockchain-backed ledger.
Explanation
What SWEAR does at runtime
SWEAR integrates with Milestone XProtect to add authenticity protection during normal video operations by:
- Reading camera stream data from the recording workflow
- Generating deterministic cryptographic hash records from video data
- Queueing and uploading those hash records through the SWEAR API
SWEAR does not:
- Re-encode or transcode camera video
- Replace Milestone recording or playback services
- Export raw video to SWEAR infrastructure
This is why the practical effect on VMS behavior is usually negligible for day-to-day operations.
Why impact is typically low
Runtime cost is concentrated in hashing and queue/upload processing, not in moving full video payloads outside the recorder. Hash records are small, outbound traffic is lightweight, and processing scales primarily with total protected bitrate (camera count x per-camera bitrate).
In steady state, this usually means:
- Low to moderate CPU use relative to available server cores
- Modest working memory footprint
- Small continuous network egress for hash-record uploads only
- Predictable disk churn from local queue persistence (insert/delete lifecycle)
How performance scales
Based on runtime modeling assumptions (not direct field benchmarking), approximate steady-state behavior is:
| 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 |
These values move up or down with camera bitrate and profile (for example, higher-bitrate 4K streams increase workload proportionally).
When you might notice temporary impact
Short-lived spikes are most likely in exception scenarios, especially:
- Backfill/catch-up periods: after service restart or downtime, SWEAR processes historical backlog faster to return to the live edge
- API/network interruptions: pending records accumulate; once connectivity returns, upload activity increases while backlog drains
- Verbose logging enabled for long periods: log growth can become operationally significant on constrained disks
These conditions are generally operational and recoverable, not normal steady-state behavior.
Practical guidance for stable performance
To keep SWEAR performance predictable in Milestone environments:
- Protect only intended camera channels
- Monitor queue trend and upload health in the SWEAR status view
- Keep network paths to SWEAR API endpoints reliable
- Use normal production log levels unless actively troubleshooting
- Plan capacity using total protected bitrate, not camera count alone
Troubleshooting cues
Use these patterns to interpret health vs. pressure:
- Healthy: generated and uploaded records both increase, queue remains stable
- Backlog forming: generated records increase faster than uploaded records, queue rises over time
- Upload stress/failure: failed/late counters rise repeatedly, queue does not drain
If backlog or failures persist, validate service health, API reachability, and logging/disk conditions, then contact support with current status counters and observation window.