VMS Server Load Fundamentals TestedBy Ethan Ace, Published Feb 11, 2014, 12:00am EST (Research)
How powerful of a server do you need to run VMS software? What drives VMS server load?
There's manufacturer recommendations but, until now, there's has never been an independent test of VMS server load.
In this report, we share our test findings experimenting with 4 VMSes (Exacq, Milestone, Axxon and Network Optix/DW) and an examination of:
- Camera count impact
- VMD impact (full stream, substream and key frame only included)
- Live viewing impact
- CPU > RAM: When building VMS server machines, money is better spent increasing processing power than adding huge amounts of memory. RAM was a factor only when advanced analytics were running on all frames.
- VMD Impact: When possible, server side motion detection should be run on secondary, lower quality streams, or keyframes only to reduce CPU usage. We recommend running motion detection on high quality or full framerate streams only when performance issues are a factor.
- Separate viewing: Viewing should be performed on a machine separate from the VMS server unless the PC is upsized with faster processing and dedicated graphics to handle this increased load. Processor usage of our low end test machine maxed at 100% at very low camera counts.
- Per camera load was an average of ~1% and under when running recording only, no viewing, and no motion detection or analytics on our test server (dual quad core i7, 16 MB RAM).
- RAM usage remained close to constant regardless of number of cameras attached. Motion detection only increased memory usage in Axxon Next, and only when detecting on all frames instead of only key frames. No other VMSs showed a steady increase in RAM usage.
- Increases due to server-side motion detection and video analytics varied widely by VMS and exact method used (all frames, key frames only, secondary stream vs. main stream, etc.).
- Increases were low (~1% CPU usage per camera or less) when performing motion detection on key frames only (or using a detection interval of 1000ms in the case of Axxon).
- Analyzing motion on all frames resulted in much higher consumption, resulting in ~4-6% increase in CPU per camera over running no server side detection.
- CPU impact when using a secondary lower resolution stream for motion detection was much lower than using high resolution streams, about a 1% increase per camera.
- Viewing client impact was moderate on our high end test machine, varying from no noticeable increase in CPU utilization to about a 17% increase (from 10% to 27% total CPU utilization) across 12 cameras at 720p30, depending on the VMS.
- However, CPU usage reached 99-100% at only five cameras when using smaller test machines typical of those used for recording in small systems (dual core AMD, 1.6 GHz, 2GB RAM).
- Our test PC was rebooted, with no VMS services started automatically, before each test, to produce an accurate baseline CPU consumption metric.
- Once booted, services for the individual VMS were started. This includes both specific VMS recording services, as well as any database or other background services required, as these contribute to load, as well.
- Measurements were taken with no cameras added, to get a baseline of performance with no archiving taking place.
- Cameras were plugged in and configured in the VMS one at a time to explicitly test impact of individual streams as they were added.
- This process was repeated for each VMS, as well as tests of different VMS functions (VMD, keyframe vs. all frame processing, etc.), with all cameras removed and re-added in the same order.
- The laptop and cameras were isolated on a separate switch, with no connection to any other networks.
- Operating System: Windows 8 Pro 64-bit
- Processor: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz (8 CPUs), ~2.4GHz
- Memory: 16384MB RAM
- Graphics card: Nvidia Geforce GT 650M, 2GB
- Operating System: Windows 7 Pro 64-bit
- Processor: AMD G-T56N Processor (2 CPUs), ~1.6GHz
- Memory: 4096MB RAM
- Integrated graphics only, no dedicated GPU
- Axxon Next: 3.5
- DW Spectrum: 18.104.22.16825
- Exacq: 22.214.171.124021
- Milestone: 2013 R2
Overall, there are three key recommendations that come out of this test:
Note that this is not an exhaustive test of all VMSs, and performance of others may vary. Users should always benchtest server configurations prior to any field deployment.
A few key trends came out of our server load testing of four VMSs:
Per Camera Impact
We began our test by adding cameras one at a time to each server, using both low end and high end machines:
High End Test Server
On average, adding a single camera increased load by approximately 1% when no local viewing, motion detection, or analytics were running. The actual observed average ranged from as little as 0.3-0.4% to ~3%. Load per camera scaled down slightly as camera count increased in some cases, with larger increases for the first or second camera (as high as 3-4%), but less so for cameras 11 and 12 (closer to the 1-2% average).
Increases in Exacq were small per camera, from 1% with one camera added, to 5% when adding 12. Axxon Next runs separate database services, accounting for a higher starting load (~5%), but per-camera increases are still low, less than 1% per camera for a total of 10%.
Low End Mini PC
Increases per camera were greater when using our AMD powered mini PCs. On average, each camera added between 1-2% CPU usage on this lower powered machine:
Server Side VMD Load
We tested server-side video motion detection using three different VMSs, each with different options for processing video.
All Frames vs. Key Frames
Analyzing motion on all frames resulted in much higher CPU consumption than only key frames (a setting allowed by Milestone and Axxon). This graph visualizes this drastic increase across eight cameras using Milestone Enterprise for no motion, keyframe only motion detection, and all frames.
Secondary Stream Analysis
Both Axxon and DW Spectrum allow motion to be analyzed using a lower resolution secondary stream, instead of the full resolution high quality stream, reducing CPU consumption. Using this feature in DW Spectrum, for example, results nearly no increase in CPU consumption for server-side motion detection on all cameras. The increase when using the high quality stream is much higher, ~11% across 12 cameras. This chart compares CPU consumption for both low and high quality streams in DW Spectrum:
Viewing Client Load
We tested VMSs on both our higher end i7 machine, as well as a lower end dual-core AMD PC. Each was tested with their viewing client open, viewing all connected cameras, to check how this affected system load.
High End Server Viewing Performance
Impact on the higher end machine, with its greatly increased processor and dedicated graphics card was moderate at most, with numbers varying by VMS. Exacq had the lowest viewing overhead, increasing only a few percent, while Axxon and DW Spectrum both increased substantially.
Mini PC Viewing Performance
However, using our smaller mini PCs, CPU usage with local viewing maxed out at 100% after only 4-5 cameras with Milestone and Exacq, clearly emphasizing the need for separate viewing client machines in even small systems.
Note that these numbers may vary, depending on VMS client settings, server hardware, and video card performance. This is intended only as a general indication of how load increases using default settings, not a definitive comparison.
When testing load, we took the following steps to ensure measurements were as accurate and repeatable as possible:
Test Machine Specs
VMS Version Information
The following versions of each VMS were used in this test:
1 report cite this report:
Back to Top