Skip to end of metadata
Go to start of metadata

Working with video content is a highly loaded task that requires the server on which WCS is installed to meet certain requirements.

The minimum server requirements are specified in the documentation, but to determine whether the hardware performance is sufficient for your project, you need to perform a series of load tests according to the conditions of your typical WCS use.

To run the test, you will need the following:

  • Virtual (VPS) or physical server
  • Video broadcast source (streaming video from OBS studio or ManyCam, broadcasting from your web or IP camera)
  • WCS server to emulate viewers of your content

Let’s check the capabilities of Linux x86_64 server with performance that meets the minimum requirements for WCS:

  • 2 GB RAM
  • 10 GB of disk space
  • 1 CPU core

Server Preparation

 1. Be sure to specify the size of Java memory heap 1 GB in the WCS server kernel launch configuration file wcs-core.properties:

-Xmx1024M

After that, restart WCS.

2. All modern server CPUs are multi-core. We will carry out load tests using only one core CPU, disabling all the others. To do this, let’s check the current status of the CPU cores used:

[root@demo ~]# lscpu | grep list 
On-line CPU(s) list: 0-3

It appears that there are 4 cores CPU (0,1,2,3) on this server. Disable all cores except the fourth:

echo 0 | sudo tee /sys/devices/system/cpu/cpu0/online
echo 0 | sudo tee /sys/devices/system/cpu/cpu1/online
echo 0 | sudo tee /sys/devices/system/cpu/cpu2/online

Current status after command execution:

[root@demo ~]# lscpu | grep list
On-line CPU(s) list:   3
Off-line CPU(s) list:  0-2

For the test, we use 1 CPU Intel Xeon E3-1240 v5@3.50GHz.

Testing

Stream transcoding test

1. We publish an RTMP stream with certain quality parameters from OBS Studio to a WCS server (an example shown in the documentation).

ResolutionBitrate, kbps
1280x720 (720p)1500


2. We transcode this stream into several popular resolutions (480p and 360p) using REST API.

ResolutionBitrate, kbps
854x480 (480p)1000
640x360 (360p)500


3. We use an example of load testing with capture of streams via WebRTC on another WCS server. With this example, we emulate viewers (subscribers) of a broadcast reproducing the stream in different resolutions (720p, 480p, 360p). At a given number of viewers (about 100), the CPU load on the WCS server is about 80%; this is the recommended maximum CPU load, at which the server functions correctly.


4. We publish two 720p streams, transcode them to 480p and 360p, add them to load testing and determine the maximum number of subscribers (about 80) of these broadcasts according to the processor load on a server with WCS (as described above, its permissible load is up to 80%).


5. Similarly, after doing a test with three 720p streams, we get a possible number of viewers of about 30.

Test without stream transcoding

1. . In this test, we’ll check how many viewers will be able to watch the broadcast without transcoding the stream on the server, i.e. we publish an RTMP stream with certain quality parameters from OBS Studio to the WCS server (an example shown in the documentation) and view it as subscribers.

ResolutionBitrate, kbps
1280x720 (720p)1500


2. We use an example of load testing with capturing of streams via WebRTC on another WCS server. With this example, we emulate viewers (subscribers) of a broadcast playing a stream from the WCS server. We increase the number of viewers until the processor load parameters on the WCS server reach 80%. When watching a 720p broadcast, we got the possible number of stream viewers – 120 subscribers.


3. We then repeat the test with 480p broadcast and load test with stream capture on another WCS server.

ResolutionBitrate, kbps
854x480 (480p)1000



4. Let’s check the capabilities of the server with 360p broadcast and load test.

ResolutionBitrate, kbps
640x360 (360p)500



Test Results

Physical server

Based on the test with the minimum recommended configuration (1 CPU, 2 GB RAM, 1 GB RAM for Java heap) on a dedicated (physical) server, we determined the approximate WCS capabilities for working with streaming video on such a server:


Without transcoding

Test

Publications

Viewers

Quantity

ResolutionBitrate, kbpsQuantity
111280x720 (720p)1500120
21854x480 (480p)1000150
31640x360 (360p)500250


With transcoding


Test
PublicationsViewers
QuantityResolution Bitrate, kbpsResolutionBitrate, kbpsQuantity

1

1

1280x720 (720p)

1500

854x480 (480p)100050
640x360 (360p)50050


2

11280x720 (720p)1500854x480 (480p)100020
640x360 (360p)50020
11280x720 (720p)1500854x480 (480p)100020
640x360 (360p)50020




3

11280x720 (720p)1500854x480 (480p)10005
640x360 (360p)5005
11280x720 (720p)1500854x480 (480p)10005
640x360 (360p)5005
11280x720 (720p)1500854x480 (480p)10005
640x360 (360p)5005

Virtual Server

A virtual server with similar parameters offers lower performance than a physical server due to a number of reasons (for example, features of a virtualization system), but allows scaling the computing power in the shortest possible time, if necessary.

Minimum recommended configuration test results (1 CPU, 2 Gb RAM, 1 GB RAM for Java heap) on a virtual server by Digital Ocean (digitalocean.com):

Without transcoding

Test

Publications

Viewers

Quantity

ResolutionBitrate, kbpsQuantity
111280x720 (720p)300050
21854x480 (480p)180070
31640x360 (360p)130070


With transcoding


Test
Publications
QuantityResolution Bitrate, kbps

1

2

1280x720 (720p)

3000

2

3854x480 (480p)1800
35640x360 (360p)1300

Cloud server (AWS for example)

Test on Amazon cloud servers (virtual and metal) were performed with the following tuning

1. WebRTC traffic encryption hardware acceleration enabled

2. Stream distribution optimization enabled

A stream 1080p with bitrate 2,2 Mbps without bitrate peaks was published to server

The following results are obtained:

Instance type

CPUs

RAM, Gb

Bandwidth, Gbps

Subscribers quantity

c5.4xlarge1632up to 101500
c5.9xlarge3672102000 (bandwidth limit reached)
c5n.9xlarge3696503000

Recommendations

According to the tests, we can conclude that a physical server with similar hardware parameters shows greater performance compared to a virtual server. A variety of devices for viewing and working with streaming video (both mobile platforms and web-integration of content) and limitations on the capacity of network channels available to viewers require significant resources for transcoding streams on the WCS server. Sample server performance requirements for WCS for typical tasks are listed below:

Subscribers quantityCPUsRAM, GBTraffic, TBUse case
up to 200485CCTV system
up to 5008166Webinars
up to 100016649Video conference
up to 2000209610HD video streaming

With more streams and viewers and complication of the business model of the project, increasing the productivity of one WCS server is impractical and leads to the emergence of a single point of failure. Scaling, geographical and logical separation (with allocation depending on the performance and role of individual servers in the CDN functions of transcoding and content delivery) allows us to flexibly determine the required level of performance for each WCS server based on the tests we have proposed and performed.