Overview
This article provides guidance on sizing a Milestone XProtect Recording Server when using the DigitalBarriersEdgeVis (or older DigitalBarriersTVIDecorder) recording driver. Testing has been performed across several Intel and AMD CPU generations to provide indicative capacity estimates based on physical core count, CPU architecture and video resolution.
Important: The benchmark figures are indicative sizing estimates under specific test conditions, not guaranteed production capacities. Actual performance depends on processor model, workload, NUMA layout and other system resources.
1. CPU performance and recording capacity
1.1 Performance by CPU generation
Manufacturer | CPU generation | Reference processor | 1080p/core | 720p/core |
Intel | Granite Rapids | Xeon 6975P-C | 1.41 | 2.81 |
Intel | Sapphire Rapids | Xeon Platinum 8488C | 1.25 | 2.50 |
Intel | Raptor Lake | Core i9-13900H | 1.07 | 2.14 |
AMD | Turin | EPYC 9R45 | 1.15 | 2.29 |
AMD | Genoa | EPYC 9R14 | 0.94 | 1.88 |
All results use H.264 codec, 15fps & continuous recording.
Encoders were configured with a 16Mbps bandwidth cap to ensure it did not bottleneck throughput.
Granite Rapids totals are extrapolated from a measured single-NUMA-region result.
2. Required Milestone Driver Proxy configuration
2.1 Why this setting matters
Milestone XProtect runs recording drivers in separate 32-bit processes known as Driver Proxy processes (ProxySrv) and each has a limited virtual address space. With a large number of EdgeVis streams in one process, memory usage can exhaust that address space and cause instability or interruptions even when the server has free physical RAM.
2.2 Required maximum devices per proxy
Setting | Milestone default | EdgeVis required value |
Maximum devices per Driver Proxy process | 100 | 15 |
Configure the maximum number of devices per Driver Proxy process to 15 before commissioning the system. This is a per-process limit, not a 15-stream limit for the Recording Server overall. Milestone can launch additional proxy processes to support more devices.
Example: With 60 streams 4 proxy processes will be launched automatically.
Milestone configuration instructions:
All benchmark results assume the maximum devices per proxy was set to 15.
3. NUMA and Recording Server performance
Non-Uniform Memory Access (NUMA) divides CPU and memory resources into regions and accessing memory attached to another NUMA region may incur additional latency. In testing, Milestone Recording Server showed inconsistent scaling when one instance spanned multiple NUMA regions. For this reason, performance was measured with one NUMA region available to each Recording Server instance.
This is particularly important for newer Intel server CPUs which use a “tile” architecture where the overall CPU is formed of multiple smaller tiles, each with their own CPU cores and memory channels.
3.1 Recommended deployment
Where practical, keep each Recording Server instance within a single physical NUMA region.
For larger hosts, consider multiple Recording Server virtual machines, one per NUMA region. (https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/configure-non-uniform-memory-access)
Assign CPU and memory resources from the same NUMA region and avoid substantial CPU overcommitment.
Do not assume a single Recording Server spanning NUMA nodes will scale linearly.
3.2 Granite Rapids extrapolation
The Intel Xeon 6975P-C reference host provided 96 physical cores across three NUMA regions. The test measured 45 simultaneous 1080p streams on one 32-core NUMA region, then multiplied that result by three to estimate a deployment of three independent Recording Server VMs.
Configuration | Physical cores | Estimated 1080p streams | Estimated 720p streams |
VM 1 / NUMA region 1 | 32 | 45 | 90 |
VM 2 / NUMA region 2 | 32 | 45 | 90 |
VM 3 / NUMA region 3 | 32 | 45 | 90 |
Combined estimate | 96 | 135 | 270 |
The 135-stream and 270-stream (720p) totals are extrapolations, not verified simultaneous three-VM measurements. Shared storage, network and memory bandwidth can affect aggregate results.
4. Physical, virtual and cloud sizing
4.1 Physical servers
Identify the exact processor and generation, count available physical cores, and inspect NUMA topology. Apply the streams-per-core estimate to the available cores. If the system exposes multiple NUMA regions, consider splitting its recording workload across dedicated instances or VMs.
4.2 Virtual machines
Do not equate a vCPU automatically with a dedicated physical CPU core: a vCPU may correspond to a hardware thread and may share its underlying core. VM sizing should consider actual physical compute entitlement, vNUMA alignment, reservation/overcommit and local memory.
4.3 Cloud deployments
The same principles apply to AWS and other providers. Identify the instance’s underlying CPU generation, effective physical core entitlement and NUMA configuration rather than estimating from vCPU count alone.
5. Benchmark configuration and method
Component | Test setting |
Operating system | Windows Server 2022 |
VMS | Milestone XProtect Corporate 2025 R3 |
Device pack | 143 |
Recording driver | DigitalBarriersEdgeVis |
Proxy device limit | 15 |
Video codec | H.264 |
Video resolutions | 1920 × 1080 / 1280 × 720 |
Encoder bitrate | 16 Mbps |
Milestone Recording mode | Continuous |
Milestone Motion detection | Enabled |
Performance threshold | 15 FPS |
Test duration | 30 minutes |
Available RAM | At least 20 GB per Recording Server |
The test increased the number of simultaneous streams while monitoring performance, with the limiting point defined by camera frame rates reaching 15 FPS.
Note: The reference CPUs had all their memory channels populated. For example, the Xeon Platinum 8488C has 8 memory channels and had 8 physical RAM DIMMS, 1 per channel. Operating with less DIMMS will limit memory bandwidth and may reduce the overall capacity of the server.
6. Detailed benchmark results
Processor | Generation | Physical cores | 1080p streams | 720p streams |
Xeon 6975P-C | Granite Rapids | 96 | 135* | 270* |
Xeon Platinum 8488C | Sapphire Rapids | 48 | 60 | 120 |
Core i9-13900H | Raptor Lake | 14 | 15 | 30 |
EPYC 9R45 | Turin | 96 | 110 | 220 |
EPYC 9R14 | Genoa | 96 | 90 | 180 |
* Granite Rapids values are extrapolated from the 32-core single-NUMA-region measurement. AMD configurations had SMT disabled while Intel systems used their reported logical processor configurations; results are therefore not strictly like-for-like architecture comparisons.
Granite Rapids had the highest estimated streams per physical core in these tests. AMD Turin provided about 22% more 1080p stream capacity than AMD Genoa at the same core count. Individual processor models within a generation may differ due to CPU frequency, thermal limits, cache and memory configuration.
7. Factors affecting real-world capacity
Factor | Sizing consideration |
CPU generation and model | Per-core throughput differs with architecture and clocks. |
NUMA topology | Cross-node workloads can scale inconsistently. |
Video resolution | Higher resolutions generally demand more resources. |
Bitrate and codec | May affect CPU, network and storage requirements; H.264 only was tested. |
Motion/recording settings | Changes to the processing pipeline can alter capacity. |
Storage and networking | Ensure sufficient sustained write and ingress bandwidth. |
Other workloads | Reserve capacity for other services and transient peaks. |
