Deploiment of 10 instances, 150 Cameras total, No GPU, Timeline only – Performance Challenges and Findings

[ucom-ux]

Hi everyone,

I would like to share our experience running Viseron in a real-world traffic monitoring environment and maybe get feedback from the community. In a separate post, we plan to share the frontend changes we made to improve usability for our specific workflow.

🎯 Use Case

We are using Viseron to monitor city traffic across:

• 150 cameras
• 18 different physical locations
• no access to camera configuration

Our goal is not AI-based detection. We are using Viseron for continuous recording, with the ability to:

• review the last hour of footage
• keep a timeline-based live view of 2 locations at a time

We prefer using the timeline as a live view interface because it makes it much easier to go back in time, instead of switching between different pages.

🖥️ Hardware Setup

Server:

• Xeon Silver 4208 (2.1 GHz)
• 48 GB DDR4 RAM (2400 MHz)
• no GPU
• 10x 1.8 TB 10K SAS drives in RAID
• VMware for virtualization
• Ubuntu 24.04.4 Live Server (VM)

⚙️ Camera Configuration

We are using a simple FFmpeg-based setup:

ffmpeg:
  camera:
    camera_1:
      name: "APASI NORTE"
      host:
      port:
      path:
      username:
      password:
      frame_timeout: 20
      record_only: true
      recorder:
        continuous_recording: true

nvr:
  camera_1:

storage:
  recorder:
    tiers:
      - path: /recordings
        continuous:
          max_age:
            days: 1
          max_size:
            gb: 5

🚨 Problems encountered (v3.5.0)

1. Scaling issues

With 80 cameras (1080p @ 25fps):

• Viseron would freeze or crash completely

With 50 cameras:

• system ran, but:
  • timeline flickering
  • hard to manage camera selection
  • manual ordering is very demanding

🔄 What we tried (v3.5.2)

Multiple Viseron instances

We deployed 10 Viseron instances on the same server, each responsible for a location.

• 5 instances were configured with a total of 50 cameras
• the other 5 instances were left blank

Results:

• improved management
• reduced timeline flickering (partially)
• still a heavy disk bottleneck
• RAM usage remained low (~11 GB total)

💡 Current workaround (v3.5.2)

• run only 2 instances at a time (~18 cameras active)
• disable recording on the others
• keep review capability only for the active instances

Additionally:

• we modified the frontend to delay "live view" by ~3 minutes

This reduced timeline flickering to a minimum (only rare occurrences now).

In the image, you can compare disk usage with 2 versus 10 instances running. The 10 instances were active from approximately 08:48 to 09:05, and then again after about 09:28.

🧪 Current testing

We are testing another machine:

• i7 (17th gen)
• 16 GB RAM
• 256 GB NVMe SSD

However, we are unsure if this will help, since the disk was stable with 2 instances.

❓ Questions

• Does double virtualization (VMware + Docker) represent a major bottleneck?
• Would using go2rtc help improve live view performance without significantly increasing CPU usage?
• Are there recommended configurations for:
  • high camera count (100+)
  • no GPU setups
• Is there a better approach for:
  • continuous recording
  • timeline stability
• Any known optimizations for disk I/O bottlenecks?
• Could the disk manager be causing the problem?
• Are there optimizations for greater RAM usage?

🧠 Key observations

• disk throughput seems to be the main limiting factor
• CPU and RAM are underutilized
• splitting instances helps, but does not fully solve the issue

Any insights or recommendations would be greatly appreciated.

Thanks!