How Many Cameras
A question that is often asked is "How many cameras can my server support?"
Well, it depends. A lot.
Zoneminder runs well on a quad core HP ML115 with 40 IP cameras. However, that's a pointless statistic since all of the following have a bearing:
- Type of use. Recording uses lots of local IO but not much CPU (Although every frame is converted to a .jpg and saved, but not otherwised changed (timestamps etc excepted)). Motion detection uses far more CPU but less disk IO.
- Obviously the hardware available makes a huge impact. RAM is always useful in a linux server, but ZM's demands are relatively modest - depending also on the size of the ring buffer, pre/post event buffers and how often the website IO is accessed. (Apache adds its own load separate to ZM)
- The type of input. IP cameras can use more CPU but it depends on the stream. Whether JPG, MJPEG, MPEG4 or whatever - each stream is handled differently and each has its own overhead. Analogue cameras are often seen as lower load, but this may be due to them having a generally lower resolution. USB cams are another example, as are file system feeds.
- The size, colour and framerate of the feed. One of the biggest newbie mistakes is to assume that CCTV cameras should be recording at 25fps when in fact it's not uncommon to see 1, 2, 3 or 5 fps used as the standard. Many IP cams allow you to specify the FPS (and ZM does it itself with JPG mode), and this also lowers the bandwidth used. Colour is often not important with CCTV, dropping to grayscale (if the camera is capable) usually drops the memory, bandwidth and cpu needs to a quarter. Size - well, bigger is better here, provided the camera is capable and doesn't blur a larger picture by upscaling. Any camera that does this should be taken outside and shot.
- Bandwidth. Not often a consideration in smaller feeds and modern gbit networks, but wireless links can become saturated and if you're taking feeds over the internet that can be a major bottleneck. There is a useful guide to working out bandwidth and IO here: FAQ#How_much_Hard_Disk_Space_.2F_Bandwidth_do_I_need_for_ZM.3F
- User loads. If you view the cameras through Zoneminder's interface you are adding a significant load to the server. With IP cams this is entirely unneccessary and can be achieved by accessing them directly. You can create montages with very simple html - a guide is here; IpCamMontage
The good news is that zoneminder has no fixed limit to the number of monitors it supports. Everything is able to be improved upon in theory and by using clusters or "super servers" you could grow a zoneminder system to quite impressive scales.
There is some help on tuning zoneminder and linux to get the most out of your Zoneminder Server: FAQ#Managing_system_load_.28with_IP_Cameras_in_mind.29
- Server hardware. Overcome by buying a bigger server, linux clustering and offloading the MySql database to another server. (This can make a big difference too!)
- CPU. Reduce size, colour, fps. Remove any shared use from the server, don't use ZM to view the cameras live if you can avoid it.
- Disk I/O. It is possible to saturate a slow HDD with zoneminder's recording even on less huge setups. SSD's are an expensive option, and Raiding and SANs produce fast results. Using fast SANs you could even allow another server to audit ZM's files via the remote Mysql database, taking another load off the main server.
- Bandwidth (IP Cams): Reduce size, colour, fps of images. If internet links, improve internet links - multiple DSLs, cable, ethernet whatever is available. If LAN: Improve network hardware. Consider creating more than one physical network and bridging on the local server in extreme cases.
In summary, Zoneminder will support as many cameras as you have the hardware available for. Every bottleneck can be overcome, but balancing the cost and need is a decision only you can make.