Understanding scalability impacts¶

This article aims to give insights about Nextcloud Talk performances to better understand impacts on hardware and network.

Video streams sent, video streams received, quality of video streams¶

From Nextcloud 24, when Talk HPB is in use, the videos not visible on the screen won't be received by the clients (although the sender is still sending a video stream).

About the video streams received, the quality of videos depends on several factors.

The videos are sent through simulcast, so there are three quality levels:

• high
• medium
• low

Now, depending on the display layout on the recipient side, the quality of the video can change:

• if speaker view is used:
  • the speaker video is received in high quality
  • the video in the bottom ribbon are received in low quality
• if grid view is used, video is received in medium quality

In addition, the quality of the video streams depends on the number of participants with video enabled:

• up to 4 participants with videos, all videos are sent in high quality
• in between 5 and 10, videos are sent in medium quality
• in between 11 and 15, videos are sent in low quality
• above 15, videos are sent in very low quality

Example: if there is a call with 30 participants and only 2 of them enables their video, then, both will send high quality videos.

In other words, NC Talk combine several factors to determine the quality of a video received by a participant, and the more participants with video there is, the lower the video quality will be (except for the speaker).

This contributes to reduce the network bandwidth needs on the server and on the clients.

Understanding impact differences between CPU & bandwidth¶

If network bandwidth is mainly impacted by video quality, CPU load is mostly impacted by the number of connection to the server. The number of connection to the server is calculated thanks to the following formula:

(number of participants - 1) * (number of participants with audio or video + number of screenshares)

Note: screen sharing is considered as an extra participant.

A few examples:

• 34 participants with audio and/or video enabled and 1 screen share makes : (34 - 1) * (34 + 1) = 33 * 35 = 1155 connections
• 34 participants with denied permissions for audio and video, and 1 presenter with video, audio and screen share makes : (34 + 1 - 1) * (1 + 1) = 34 * 2 = 68 connections

Impact of the number of connections on hardware¶

The CPU consumption of the WebRTC gateway depends a lot more on the number of connections it handles than on the quantity of data it relays (video quality). Reduce the video quality reduces the need for network bandwidth, but has nearly no impact on the CPU load.

Reducing the number of participants with audio or video permissions will decrease the number of connections to the server and will reduce the load on the CPU. This is also valid for CPU on the client side.

Note: for this to work, it is not enough that participants simply turn off their microphone and camera. It is mandatory that a moderator denies audio and video sharing permissions to the users in the conversation settings.

To summarize:

• reducing the video quality has an impact on the network bandwidth needed.
• the number of connections impacts the CPU on the server and on the client side.

For example: A Talk HPB running with an Intel Core i7-6700 CPU @ 3.40GHz can handle about 1200 connections simultaneously. This means, that this HPB can handle:

• a call with ~34 participants with all audio and video permission and one screen share (33 * 35 = 1155 connections)
• a call with ~600 listeners (with denied permissions for audio and video) and one presenter, with audio, video and screen sharing ((600-1) * (1 + 1) = 1198 connections)

Adding an extra CPU would allow the server to handle ~2400 connections, enabling it to host:

• a call with ~49 participants with all audio and video permission and one screen share (48 * 50 = 2400 connections)
• a call with ~1200 listeners (with denied permissions for audio and video) and one presenter, with audio, video and screen sharing ((1200-1) * (1 + 1) = 2396 connections)
• a call with ~600 listeners (with denied permissions for audio and video) and 3 presenters, with audio, video and 1 screen sharing ((1200-1) * (3 + 1) = 2396 connections)