Fonctionnalité Live — Retour d'utilisation

Booteille · Novembre 25, 2020, 11:43

Avec les copains du Canard Réfractaire, à l’occasion de l’université confinée que l’on organise, nous avons fait un premier test de la fonctionnalité Live sur un serveur de développement.
Voici les retours de l’administrateur :

Mes conclusions suite a ce premier test : On à streamé en live sur peertube pendant 1h40. Je crois qu’on était une grosse dizaines de personnes a regarder le live au pic de fréquentation. Et vu les consommations de ressources faut pas esperer dépasser une quinzaine de personnes sur la bande passante réseau de mon serveur de test :

Quand on ne streame que la voix et l’écrit vocal ca ne consomme pas trop de bande passante.

Mais dès qu’on a essayé de streamer une vidéo c’est vite monté a 60-70% des 100Mbps de bande passante.

Niveau RAM ca consommait 1.5 Go plus le cache sur les 4Go que j’y ai mis

et niveau CPU les 4 vCore que j’avais alloué à la VM étaient utilisés à 50-70%.

L’utilisation CPU ne devrait pas trop augmenter en fonction du nombre de spectateurs, vu que c’est essentiellement utilisé pour le transcodage. Idem pour la RAM. La bande passante réseau par contre faut s’attendre a ce que son utilisation augmente bien. Même si le protocole p2p décharge un peu le serveur ce n’est pas fou. Les contraintes de la diffusion en live font que ca limite les bénéfices de cette technique.

Faudrait donc voir ce que ca donne sur le serveur coin (celui qui héberge canard.tube) qui lui a 10 fois plus de bande passante, enfin sur le papier, le même nombre de vCore et devrait être large en RAM avec ses 8Go même en mettant les deux instances peertube en parallèle.
Et faudrait tester l’impact de streamer en 1080p comparé à du simple 720p qui serait peut-être suffisant. Par contre dans l’idéal il faudrait recruter plus de monde pour tester la montée en charge à un niveau plus important. Mais je ne sais pas si on peut mobiliser beaucoup plus de monde avant le jour J.

Et sinon le replay à bien fonctionné donc cette fois avec le transcoding activé (en 1080p et 720p). Il consomme 5Go de disque (50,33 Mo par minutes pour pile 100 minutes de live pour être précis mais vu que ca n’a pas l’air d’être du bittrate constant ca doit dépendre de ce qu’on streame)

Chocobozzz · Novembre 25, 2020, 12:43

Hello,

Merci du retour !

lareinedeselfes · Novembre 25, 2020, 5:50

tu sais où demander du monde si tu en as besoin

Booteille · Novembre 25, 2020, 9:45

Ouaip. Merci !

On va probablement refaire un ou plusieurs tests, on vous tiendra au jus !

12b · Novembre 27, 2020, 3:52

Salut,

Quelques compléments d’info par rapport à mes premiers commentaires sur nos tests de streaming live que @Booteille à posté plus haut :

J’avais fais un premier test avec aucun transcodage d’activé. En live ça avait bien fonctionné mais la publication du replay avais produit une vidéo toute noire (et sans son je crois)

Pour les tests suivant j’avais activé le transcoding, en 1080p et 720p. Et la publication des replay avait bien fonctionné.
J’avais essayé de regarder le live en passant par une autre instance qui suivait l’instance où ou le live était publié mais ça n’avait pas fonctionné. Le deuxième serveur était en version release 2.4.0, pas en version développement donc je me suis dit que c’était peut être normal. Mais nous venons de refaire un essai avec deux serveurs en version développement et ça ne fonctionne pas non plus.

Edit: Ce test était toujours en cours au moment où j’avais écris le message ci-dessus et j’avais donné les URL du stream sur les deux serveusr. Le test étant maintenant terminé j’ai supprimé ces informations

Chocobozzz · Novembre 27, 2020, 4:08

Hello,

Yep c’est normal. Seules les instances en 3.0 pourront voir les autres lives.

Un grand merci, je viens de trouver le bug. Je corrige ça de suite (normalement la nightly de demain devrait corriger le soucis : Fix cors on sha segment endpoint · Chocobozzz/PeerTube@4a7f902 · GitHub)

12b · Novembre 27, 2020, 7:14

Je confirme, ça fonctionne parfaitement maintenant
Et bravo pour cette nouvelle fonctionnalité de streaming en live!

12b · Novembre 27, 2020, 8:55

Par contre j’ai l’impression que tous les clients recevaient le flux vidéo depuis le serveur sur lequel était envoyé le live, même si ils le visionnaient en passant par l’autre serveur. Il n’y avait quasiment pas de trafic réseau sur le second serveur.

Est-ce qu’un mécanisme de redondance similaire à celui des vidéo normale est censé fonctionner à ce stade du développement de la fonctionnalité live ou bien est-ce pour plus tard?

rigelk · Novembre 27, 2020, 9:38

Non, et aucun n’est prévu pour l’instant étant donné la difficulté de télécharger et informer le serveur des segments disponibles en mirroir sans doubler la latence.

Chocobozzz · Novembre 28, 2020, 10:13

Je pense qu’il y a plusieurs possibilités de redondance entre instances pour le live, mais je ne les ai pas encore vraiment étudié. Pour l’instant on essaye de faire un truc qui fonctionne, et il faudra voir où sont les réels bottleneck (des fois on est surpris :)).

12b · Novembre 28, 2020, 2:44

Oui pas de soucis. C’est un sujet complexe qui mérite d’avancer étapes par étapes. Ma question était juste pour clarifier là ou vous en étiez et confirmer que ce n’était pas une mauvaise configuration de ma part.
Concernant les bottlenecks j’aurais plus d’info à vous donner en fin de journée suite au tests que j’ai réalisés depuis hier et à la répétition que nous allons faire cet après midi pour préparer l’événement du WE prochain que je compte essayer de streamer via peertube. Mais je ne sais pas si ce forum est le meilleur endroit pour postertous les détails des différentes conditions de test que j’ai essayé, de l’utilisation CPU et réseau ainsi que les aléas rencontrés. Est-ce que ça serait mieux que je poste dans des issues sur GitHub ou sur FramaGit ou bien je continue ici?

Chocobozzz · Novembre 29, 2020, 10:33

Ici ça me parait bien, et si besoin on créera des tickets sur github.

JohnLivingston · Novembre 29, 2020, 11:22

Merci pour les retours ! J’ai trop hâte que tout ça soit dispo en version stable !

12b · Novembre 30, 2020, 12:30

Petit soucis d’augmentation de l’utilisation CPU du serveur dans le temps lors d’un live

Sur un des premiers essais que nous avons fais avec plusieurs utilisateurs qui regardaient le stream (environ une douzaine) tout se passait bien au début. Mais au bout d’un moment les utilisateurs on commencé à ressentir du lag. Et au même moment l’OBS utilisé pour générer le stream a commencé à avoir son compteur de dropped frames qui s’incrémentait.
Le problème ne semblait pas venir de l’utilisation mémoire, des disques ni de la bande passante réseau. Seule l’utilisation CPU sur le serveur semblait significative, sans toutefois saturer complètement les capacités du serveur.

Comme il y avait plusieurs paramètres changeant pendant le déroulement du test il n’était pas évident de comprendre ce qui s’était passé

nombre de clients qui visualisaient le stream non constant
flux vidéo qui passait d’images relativement statique a des séquence avec plus de mouvements

Il semblait y avoir une tendance dans l’utilisation CPU qui augmentait pendant le déroulement du test.

Mais en première analyse l’hypothèse était que que ffmpeg utilisait trop de CPU pour le transcoding dans les phases où le flux vidéo était très dynamique où bien que nous avions atteint un nombre trop important d’utilisateur pour ce serveur a un moment donné du test.

Exemple d’utilisation CPU lors d’un de ces premier test :

Cependant des test supplémentaire réalisé dans le but de déterminer des valeurs optimales pour la résolution de streaming et les résolutions de transcoding ont montré que dans certaines configuration de streaming le niveau de CPU augmentait de manière linéaire au fur et a mesure de la durée de streaming alors que rien de changeait au niveau du nombre de client regardant le stream ou de la dynamique du flux vidéo.

Exemple, test d’une heure de streaming avec

un seul client visualisant le live
4 résolutions de transcoding d’activées
publication du replay activée

Le début du palier dans l’utilisation CPU vers la fin correspond au moment ou OBS commençait à avoir des dropped frames.
La rampe d’utilisation mémoire un peu après correspond au moment ou OBS à perdu la connexion avec le serveur qui a alors fermé le stream et à commencé à publier le replay.

Test d’une heure de streaming avec :

un seul client visualisant le live
**1 seule résolutions de transcoding d’activée **
publication du replay activée

On peut voir sur ce test qu’avec moins de résolutions de transcoding d’activées l’augmentation d’utilisation CPU a été plus lente.

On a donc essayé de faire un test sans transcoding du tout :

un seul client visualisant le live
**pas de transcoding activé : **
publication du replay activée

Mais il y avait toujours une augmentation de l’utilisation CPU dans le temps.

Première heure de streaming :

Après environ 10h30 de streaming :

Graphe sur toute la durée du test :

Ce n’est qu’en désactivant la publication du replay que l’utilisation CPU semble rester stable, même en avec du trascoding activé.

Exemple, Test de 13h30 avec

un seul client visualisant le live
1 résolutions de transcoding d’activée
publication du replay désactivée

Les différents paliers d’utilisation CPU et réseau correspondent à des changements qui ont eu lieu dans la vidéo qui était streamée, pas à un comportement anormal du serveur peertube.

Durée totale du test :

Dernière heure du test :

Il semblerait que l’augmentation de CPU soit corrélée au nombre de fichiers générés dans /var/www/peertube/storage/streaming-playlists/hls/<hash-de-la-vidéo> (entre 2000 et 4000 fichiers vers la fin des tests ci dessus sauf le dernier ou seuls les quelques fichiers les plus récent sont conservés par le serveur)

12b · Novembre 30, 2020, 12:38

Un petit glitch cosmétique au démarrage d’un live :

Chocobozzz · Novembre 30, 2020, 9:02

Un grand merci pour le super rapport. Vous utilisez quoi comme machine/OS ?

12b · Novembre 30, 2020, 10:18

De rien c’est un plaisir de tester peertube.

Mon serveur de test (dev.tube.distrilab.org) tourne dans un conteneur LXC sous l’hyperviseur Proxmox VE 6.2 / Debian 10 (Buster). l’OS du conteneur est Debian 10 également.

Conteneur LXC :

4 vCore
6 GB RAM
32 GB de disque

Hote Physique : Serveur dédié chez Online/Scaleway modèle « Dedibox Pro-2-M-SATA »

4 Cores / 8 Threads (Intel® Xeon® CPU E3-1230 v3 @ 3.30GHz)
32 Go RAM,
2x 1.8 To HDD en RAID-1
100 Mbit/s de bande passante internet

Et le serveur de « prod » du canard réfractaire (fait en fait tourner deux instances peertube en ce moement, canard.tube en v2.4 et live.canard.tube en version dev ) est un VPS chez OVH modèle « Comfort »

4 vCore
8 Go RAM
160 Go SSD NVMe
1 Gbit/s de bande passante internet

Les graphes de CPU ci-dessus ça vient de l’interface ProxMox du serveur de test. Faut qu’on installe quelque chose pour avoir du monitoring sur l’autre serveur mais on a pas encore pris le temps de le faire.

Chocobozzz · Novembre 30, 2020, 3:03

Du coup je pense (espère ?) que ce patch devrait résoudre le soucis : https://github.com/Chocobozzz/PeerTube/commit/937581b8f61fe82fdac044e11740b9a4cb6d96b0

À tester à partir de demain

Booteille · Décembre 1, 2020, 12:01

On a refait un test, le patch est fonctionnel, 12b va te faire un retour plus tard.

Juste, j’ai constaté un bug cosmétique sans importance :
Après le stream, j’ai pu accéder au replay et le regarder sans le moindre problème, la vidéo se jouait normalement jusqu’à la fin mais la longueur totale de la vidéo indiquée était erronée.
Elle indiquait 1:06:00 quand la vidéo faisait au total, en réalité, 1:06:15.

Aussi, je ne pouvais pas aller plus loin que 1:06:00 quand je souhaitais cliquer sur un temps précis sur le curseur de la vidéo.

Regarde le temps « en cours » vs « total ». Et le curseur sur la deuxième image.

J’espère être clair dans mes explications, il est un peu tard.
Merci pour le fix éclair en tout cas. C’est propre ! À priori, on pourra streamer sans problème l’évènement du week-end prochain.

12b · Décembre 1, 2020, 12:55

Oui donc après un test de live d’une heure avec ces paramètres

streaming en 720p
transcoding activé en 720p et 480p
publication du replay activée

La CPU reste bien stable maintenant :

Pour valider ce que nous comptons faire le WE prochain on a aussi testé de relancer un autre live juste après l’arrêt du premier pour voir si tout se passait bien sur ce deuxième live pendant que le replay du premier était publié. Il n’y a pas eu de soucis, aucune dropped frame de signalée par OBS sur le deuxième live.

L’utilisation CPU du serveur environ une demi heure après le basculement du premier au deuxième live :

Le basculement du premier au deuxième live était à 0h33
Les infos d’exécution du job « video-live-ending » :

Processed on Dec 1, 2020, 12:38:14 AM
Finished on Dec 1, 2020, 12:40:17 AM

Après l’arrêt du deuxième live :

L’utilisation mémoire a l’air stable également :

Merci pour la réactivité des fix!