Metrics: Project Load Testing

Date: June 19th, 2026

As part of our development process, we must define and measure performance indicators regarding the complete solution (both the OBS part and the web application part).

Web Part

One of the key points during a load test is to reproduce real public deployment conditions.

To learn more about the deployment architecture, you can check the deployed architecture document.

Thus, in order to successfully conduct this load test, we use our self-hosted development virtual machine. The configuration is as follows:

• Host machine
  • Intel i3 11400H (6c/12t) 2.7 GHz
  • 32 GB RAM DDR4
  • Proxmox 8.2.2 (kernel 6.8.4-2-pve)
  • 500 GB NVMe + 1 TB SATA SSD
  • 500 Mb/s fiber optic
• Virtual machine
  • 3 vCPUs
  • 6 GB RAM
  • 200 GB (shared SATA SSD)
  • Debian 12

Proxmox view:

IDLE Scenario

The first scenario we developed reflects a complete lack of platform usage. This is the deployed web stack with no clients connected (0 spectators, 0 streams).

This scenario allows us to obtain a baseline reference to compare results with future load tests.

Here are the measurements recorded in terms of CPU usage, memory, disk I/O, and network bandwidth on the virtual machine over a 24-hour period:

Conclusion

• CPU usage is very low (< 1.3%), mainly dominated by background processes of the virtual machine and Docker.
• RAM usage is stabilized at 1.5 GB (+ 1 GB of buffers and 3 GB of cache).
• Network usage is negligible (< 100 bytes/s).
• Disk I/O usage is also negligible (< 40 ko/s, generated by the VM logs).
• Storage occupation is 19 GB (this includes the system, dependencies, GitHub Actions for automated deployment, and the complete web stack).

Low Load Scenario

This second scenario represents the case of a single streamer (broadcasting 4 audio and video streams) with a single spectator.

Screenshot of the test configuration.

Here are the measurements recorded in terms of CPU usage, memory, disk I/O, and network bandwidth on the virtual machine over a 15-minute period:

CPU usage climbs to about 4.1% - 4.2% when starting the stream.

Network traffic (Netin and Netout) jumps to about 1.1 - 1.2 MB/s (i.e. ~9-10 Mb/s).

Disk writing intensifies to reach 1.2 MB/s during HLS segment creation.

Process details: FFmpeg and Node.js become the main consumers.

Results Analysis

• CPU: A clear increase is observed, going from 1.3% to 4.1%. This moderate rise is explained by the SRT ingestion management and HLS segmentation performed by FFmpeg for the 4 isolated streams.
• Network: Incoming throughput (~1.2 MB/s) matches the stream sent by OBS, configured here at about 8,170 kb/s. Outgoing throughput is equivalent, as the server retransmits these segments to the single spectator.
• RAM Memory: Usage remains stable around 5.5 GB (92%) in Proxmox, as a large portion is mobilized by system cache, although real process consumption (viewed via htop) is only 1.56 GB.
• Storage and I/O: Disk writing of 1.2 MB/s is directly correlated with FFmpeg’s activity, which continuously generates and deletes .ts video fragments for the HLS playlist.

Low Load Test Conclusion

The FOV solution behaves stably for a single stream. The bottleneck is not the CPU, but primarily the network bandwidth, which evolves linearly with the number of tracks sent by the streamer (here 4 tracks for ~1.1 MB/s).

The current virtual machine (3 vCPUs) appears capable of supporting about 20 to 25 simultaneous streamers in this configuration before reaching CPU or network saturation.