Does SWEAR impact Milestone VMS performance?
In Short
In normal operation, SWEAR does not materially impact Milestone recording, playback, or core storage workflows. SWEAR runs as a sidecar-style certification service: it reads recorded stream data, generates cryptographic hash records, and uploads only those compact records. It does not alter camera video, does not replace Milestone recording logic, and does not send raw video off-host.
At scale, runtime impact is typically low and predictable, with resource use driven mainly by the number of protected cameras and their bitrate. The most noticeable load is usually temporary, such as when the service catches up after downtime or when network/API interruptions create a queue backlog. With standard deployment settings and healthy connectivity, SWEAR stays near steady state and operates with minimal operational disruption.
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.