We (Seneca) have been doing some performance testing on the new ONSSI v5.1 code in our lab the past couple of weeks as part of our regular rotation of testing performance of VMSs on our servers and learning what to put in the box and what to set to make it run better.
As a result, We have learned a few things you can do to help your system run its best that I thought would help out fellow IPVM'rs.
The good news is that the new code does run quite well from a performance perspective, but you need to have the right mix of hardware resources to do it.
One basic assumption is you will NOT run more than one stream in the Client on your recorder as it will take away important resources from your recorder engine.
This is a statement that is true for any VMS recorder that is especially important when doing higher total input beyond 200Mbits/sec.
Historical ref
For those of you who are familiar with how the older Recorder used the fast LiveDB and slower ArchiveDB, you will be pleased to know that the new version has done away with the LiveDB part but now requires more memory in the system because THAT is where the new LiveDB lives.
How much? Please keep reading.
System Setup Pieces
The first thing to consider is how you will want to setup your Base, Core and Recorder functions.
The simple choice is all-in-one and the more complex choice is separated.
The separated configuration means that the Base and Core functions are on a system and the Recorder(s) are on different systems.
The hardware effects of this choice are related to CPU and Memory.
The All-in-one choice demands more memory and CPU because of the extra function it is performing in addition to Recording.
Of course the upside here is that you only need one system to manage and record your video.
My recommendation here is to use 16GB as a minimum. If you have a higher camera count (200+)...be thinking of 24GB or more.
Use a higher class e3 Xeon (a 124x over a 122x).
The separated choice will have the 'Master Core' function installed on the system where the Base is installed. The Recorder system(s) will be installed without the Core function. This setup is accomplished using the custom installation option at the present time.
Think of the 'Core' function as the old Management Client. This function owns all the setup and configuration of all the recorders in your installation.
The benefit of this configuration is that each Recorder can now handle MORE cameras on the same hardware.
Motion Detection
Another important consideration is how Motion Detection is used. The traditional ones being on the camera or on the server.
If you run MD on the the Recorder... be prepared to add more memory or drop the number of cameras you are running on the recorder. The memory will usually be the first thing that you run out of. Of course if your CPU is under-powered you will max that out.
Storage
The Storage is called 'Zones' in this version and be sure to use a directory name when you set them up.
We did all our testing with the Zone full.
We did notice that when the Zone fills up, it will call in a 'trimming function' to make space for the new data as you would expect.
If you are near the system performance boundary, this mode of trimming has a modest negative effect where it could drop some frames, usually from just one camera.
A better way to keep enough room for you camera data is to establish a proper sized 'Aging' time.
When the 'Age' cleanup is called, it is much more polite to the performance envelope.
Where is the Health info?
The code keeps a number of log files in the Program Files\ONSSI directory under each of the installed functions.
The DM logs are for the devices. The MDS logs are for the storage. There are several others, but these two are the most important ones for a Recorder.
Some example numbers....
On a good quad core e3-Xeon with 16GB memory...
All-in-one with Motion on Server... you can handle about 100 720P-30FPS streams (230-280Mbits/sec).
Separated Recorder..same build.... you can handle 180 of the same streams and be taking in 400-450Mbits/sec.
With the server side motion off, you will be handling nearly 2X the stream count.
I do not recommend doing more than 400-450Mbits on a Recorder doing Server Side Motion at this time.