Lead Forensics

Call Us Now +44 (0) 20 3475 5743

How do you benchmark throughput on a surveillance server?

  • Posted by: admin

To benchmark throughput on a surveillance server, you measure how much video data the system can continuously write to disk without dropping frames, expressed in megabits per second (Mbps) or megabytes per second (MB/s). The benchmark must reflect real-world conditions: simultaneous streams, mixed resolutions, and sustained recording over time rather than short peak bursts. The sections below answer the most important questions surrounding surveillance server throughput testing, from the metrics that matter to knowing when to re-run your tests after deployment.

What metrics actually define throughput on a surveillance server?

Surveillance server throughput is defined by the maximum sustained data write rate the system can maintain across all active camera streams without frame loss, buffering, or storage queue overflow. The primary metric is aggregate write throughput in Mbps or MB/s, but a complete benchmark must also capture CPU utilisation, RAM headroom, disk queue depth, and network interface saturation simultaneously.

Focusing on a single metric gives an incomplete picture. A server may pass a write-speed test in isolation yet fail under real deployment conditions because the CPU is simultaneously decoding streams for live view, running motion detection, or feeding analytics processes. Effective benchmarking treats the server as a system under combined load, not a collection of independent components.

The metrics that matter most in a surveillance throughput benchmark are:

  • Aggregate write throughput (MB/s): The total sustained data rate across all storage arrays during continuous recording
  • Frame drop rate: The percentage of frames lost under full load: zero is the only acceptable figure for mission-critical deployments
  • CPU utilisation under load: Sustained CPU usage should leave sufficient headroom for analytics, live viewing, and export tasks
  • Disk queue depth: A growing queue signals the storage subsystem cannot keep pace with incoming data
  • Network interface utilisation: Confirms that the NIC is not the bottleneck before storage or CPU limits are reached

How do camera resolution and bitrate affect throughput requirements?

Camera resolution and bitrate are the two biggest drivers of surveillance server throughput requirements. Higher resolution cameras produce larger video files per second, and higher bitrates increase the data volume the server must write continuously. A single 4K camera stream encoded at 20 Mbps demands roughly four times the throughput of a 1080p stream at 5 Mbps, so camera specification directly scales storage and processing demands.

The relationship is not simply additive. When you combine dozens or hundreds of streams, compression format also plays a significant role. H.265 (HEVC) delivers comparable image quality to H.264 at roughly half the bitrate, which meaningfully reduces the aggregate throughput the server must sustain. Variable bitrate (VBR) encoding complicates benchmarking further because streams spike during motion events, meaning peak throughput can be substantially higher than the average figure.

When calculating throughput requirements, designers must account for:

  • The number of cameras multiplied by each camera’s maximum bitrate
  • The compression codec in use across the installation (H.264, H.265, MJPEG)
  • Whether streams use constant bitrate (CBR) or variable bitrate (VBR) encoding
  • Concurrent live-view decoding loads on top of recording workloads
  • Analytics processing that adds additional CPU and sometimes GPU demand per stream

Ignoring peak VBR spikes is one of the most common causes of under-specified surveillance servers. A system sized to handle average bitrates will frequently drop frames during busy periods such as rush hours, crowds, or alarm events, precisely when reliable recording matters most.

What tools and methods are used to test surveillance server throughput?

Surveillance server throughput is tested using a combination of synthetic load tools, VMS-based stress testing, and purpose-built simulation utilities that replicate real camera workloads. The most accurate method simulates the exact camera mix, resolutions, frame rates, compression formats, and analytics loads of the intended deployment before any hardware is physically installed.

Synthetic and OS-level disk benchmarks

Tools such as CrystalDiskMark or Iometer can measure raw sequential write speeds on storage arrays, which establishes a theoretical ceiling. These tests are useful for validating RAID controller performance and drive array configuration, but they do not reflect the mixed read/write patterns, metadata overhead, or CPU contention that occur during live surveillance recording.

VMS-integrated load testing

Most enterprise Video Management Systems include diagnostic dashboards that report live recording throughput, frame rates per channel, and storage queue status. Running a full-camera simulation through the VMS itself, with all streams active simultaneously, gives a far more realistic picture than synthetic disk benchmarks alone. This method requires either live cameras or a camera emulator capable of generating genuine RTSP streams at the target bitrate.

Purpose-built simulation utilities

The most rigorous approach uses a dedicated hardware simulation tool. Secure Logiq’s proprietary Logiqal Benchmark utility allows systems designers to virtually deploy an entire multi-camera IP surveillance network, simulating exact camera resolutions, compression formats, frame rates, and analytics workloads, to stress-test and validate server throughput before physical deployment. This eliminates the guesswork that comes from extrapolating synthetic results to real surveillance environments and gives design teams a defensible, documented performance baseline ahead of installation.

What’s the difference between rated throughput and sustained throughput?

Rated throughput is the maximum data rate a server or storage component is specified to handle under ideal, short-duration conditions. Sustained throughput is the data rate the system can maintain continuously over hours or days without degradation, frame loss, or thermal throttling. For surveillance applications, sustained throughput is the only figure that matters operationally.

The gap between rated and sustained figures can be significant. A storage controller rated at 2,000 MB/s may deliver that figure in a 10-second burst test but settle to 800 MB/s under the continuous sequential writes that characterise 24/7 HD video recording. Similarly, a CPU rated for a high clock speed may throttle under sustained thermal load, reducing decoding capacity during long recording sessions.

Surveillance-specific hardware addresses this gap by engineering for sustained workloads from the outset. Enterprise-grade, 24/7 surveillance-optimised drives, battery-backed hardware RAID controllers, and OS isolation via dedicated SSD pairs all contribute to closing the difference between rated and real-world sustained performance. A benchmark that does not run for at least several hours under full load cannot reliably confirm sustained throughput.

How do RAID configuration and storage architecture affect throughput results?

RAID configuration has a direct and measurable impact on surveillance server throughput benchmarks. Different RAID levels trade write performance against redundancy, and the wrong choice for a high-camera-count deployment will create a storage bottleneck even when individual drives are fast. Hardware-accelerated RAID consistently outperforms software RAID in sustained write scenarios because it offloads parity calculation from the main CPU.

RAID level selection and write performance

RAID 5 offers a good balance of capacity, redundancy, and write performance for most surveillance deployments. RAID 6 adds a second parity drive for greater fault tolerance but introduces a higher write penalty, making it better suited to larger arrays where drive failure risk increases. RAID 60, which stripes across multiple RAID 6 groups, is used in the highest-density enterprise deployments to achieve very high aggregate throughput while maintaining dual-drive fault tolerance across each sub-group.

OS isolation and storage architecture

A frequently overlooked factor in throughput benchmarking is whether the operating system shares storage with the video recording arrays. When the OS competes with video writes on the same physical drives, disk queue depth rises and sustained write performance falls. Isolating the OS onto dedicated enterprise SSDs configured in RAID 1 keeps the primary recording arrays free for sequential video writes, which is the workload they are optimised to handle. Hot-spare drives configured within the array ensure that a single drive failure does not interrupt recording while the array rebuilds, which would otherwise cause a temporary throughput drop visible in benchmark results.

When should you re-benchmark a surveillance server after deployment?

A surveillance server should be re-benchmarked whenever a significant change is made to the system that could alter its throughput profile. This includes adding cameras, upgrading to higher-resolution or higher-bitrate streams, enabling new analytics workloads, expanding storage arrays, or updating the VMS platform to a new major version. Re-benchmarking confirms that the system still has adequate headroom after the change.

Beyond change-driven testing, periodic re-benchmarking is good practice for long-running installations. Drive performance can degrade subtly over time, particularly in arrays that have experienced a rebuild event following a drive failure. RAID rebuilds stress remaining drives and can leave the array in a slightly degraded performance state that only becomes apparent under full load. Running a throughput benchmark after any rebuild confirms the array has returned to its expected sustained write rate.

Specific triggers for re-benchmarking include:

  • Adding 10% or more cameras to an existing installation
  • Switching compression codecs across a significant portion of the camera estate
  • Enabling video analytics or AI inference workloads on streams that were previously recorded only
  • Replacing or expanding storage arrays, including adding drives to existing RAID groups
  • Following any RAID rebuild event caused by drive failure
  • Major VMS version upgrades that change how the software manages disk I/O
  • Annual performance audits for critical infrastructure or high-security environments

Re-benchmarking is also valuable before a warranty or support contract renewal, as documented performance data provides an objective baseline that simplifies any support escalation or hardware replacement discussion.

How Secure Logiq helps you benchmark and validate surveillance server performance

Secure Logiq provides surveillance infrastructure specifically engineered to deliver measurable, guaranteed throughput under real-world recording conditions. Rather than leaving performance validation to guesswork, the company combines purpose-built hardware with dedicated pre-sales design support to ensure every system is correctly sized before installation.

  • Logiqal Benchmark simulation: Secure Logiq’s proprietary utility virtually deploys your entire camera network, including exact resolutions, codecs, frame rates, and analytics loads, to validate server and storage throughput before any hardware ships
  • Surveillance-optimised hardware architecture: Every enterprise server features OS-isolated dual SSDs, hardware-accelerated RAID arrays with hot-spare drives, and 24/7 surveillance-grade storage to close the gap between rated and sustained throughput
  • Certified VMS compatibility: Servers are tested and certified against leading platforms including Milestone XProtect, Genetec Security Center, and Avigilon Unity, removing compatibility variables from your benchmark results
  • Performance guarantees: Secure Logiq officially guarantees the throughput, storage retention, and performance of its engineered configurations, giving integrators and end-users a documented, defensible baseline
  • 48-hour soak testing: Every server undergoes rigorous extended testing at the Crawley manufacturing facility before dispatch, confirming sustained rather than peak performance

If you are specifying or deploying HD surveillance infrastructure and need confidence in your throughput figures, speak to the Secure Logiq design team to run a pre-deployment simulation for your camera estate.

Related Articles