Ce vendredi 30 décembre 2022, Octopuce a participé à un test de charge en live d’un Peertube avec David Dufresne, aka Davduf, rédacteur en chef du média AuPoste.fr que nous hébergeons. Ce billet de blog revient sur ce test, et propose des analyses techniques et quelques conseils pour les personnes administrant un ou plusieurs Peertube.

Introduction : Peertube, le P2P, le live, le chat

Tout d’abord, qu’est-ce que Peertube ? Peertube est un logiciel libre développé par Chocobozzz et financé par Framasoft, grâce aux dons. Ce logiciel permet de diffuser des vidéos en ligne, soit à la demande, soit en direct. La diffusion des vidéos est facilitée par un système technique pair-à-pair qui fait que ce n’est pas seulement le serveur Peertube qui sert les vidéos aux visiteurs mais chaque visiteur d’une vidéo sert aussi des morceaux de ladite vidéo aux autres visiteurs au même moment. Cela permet d’économiser de la bande passante, donc d’héberger de gros Peertubes sur de petits serveurs. De plus, Peertube met en œuvre le protocole ActivityPub, qui permet par exemple de commenter des vidéos Peertube depuis son compte Mastodon ou Pleroma (réseaux sociaux distribués similaire à Twitter).

Depuis quelques versions, Peertube permet de diffuser des vidéos en live, comme le permettent YouTube ou Twitch. Ces lives disposant du même système de partage en Peer-to-peer, il est donc théoriquement possible de tenir plusieurs centaines ou milliers de visiteurs en parallèle sur un petit serveur. Ce test de charge avait pour but de vérifier cette idée.

Enfin, contrairement à Youtube ou Twitch, Peertube ne disposait pas jusque là d’un système permettant de chatter entre visiteurs lors d’un live. Grâce à John Livingston, développeur indépendant en logiciel libre, il est désormais possible de disposer d’un greffon de chat sur son Peertube pour permettre cet usage. L’objectif de ce test de charge était donc aussi de tester la capacité du système de chat de fonctionner avec un grand nombre d’utilisatrices/teurs.

C’est donc dès jeudi 29 que l’équipe d’Octopuce s’est mobilisée pour préparer le Peertube de AuPoste pour pouvoir recevoir un nombre indéterminé (mais grand) de visiteurs simultanés sur le live et le chat du Peertube. Dans le paragraphe suivant, nous allons vous donner les détails des outils techniques mis en œuvre pour ce test.

La préparation du test de charge : pousser les curseurs !

Comme tout logiciel serveur, Peertube consomme des ressources informatiques pour fonctionner : mémoire (RAM), temps de calcul (CPU), accès aux disques SSD (IO), bande passante (NET). Nous souhaitions pouvoir servir un grand nombre d’internautes mais ne connaissions pas avec certitude les ressources requises pour cela. Or, Octopuce dispose « pour en cas de besoin ou panne » de serveurs non utilisés plutôt puissants. Nous avons donc choisi, la veille du test, de déplacer la VM du Peertube de Davduf sur une de ces machines. Cela permet de disposer de puissance importante sans risquer de déranger un voisin de serveur, et cela enlève le facteur CPU/RAM/IO comme limite au nombre de visiteurs que l’on pourra servir : avec une machine à 80 cœurs et 440G de RAM sur 6 SSD en RAID, on était tranquille ! Enfin, cela nous permettra, quelque soit le nombre de visiteurs, de mettre un nombre en face de la puissance requise. En pratique, nous avons alloué 66 threads de Xeon Gold 6230 et 256G de RAM à cette VM.

Nginx & HTTP/3 – Quic

Ensuite, comme Octopuce l’expérimente déjà avec succès depuis environ 6 mois, nous avons la possibilité d’ajouter le support de Quic, appelé aussi HTTP/3 à nos serveurs web. Ils sont déjà activés sur nos S3/Minio, et nous avons donc activé ce nouveau protocole sur le serveur web du Peertube de Davduf : ce protocole, descendant de HTTP/(1.0/1.1/2.0) (le service web « traditionnel ») permet de s’économiser des échanges complexes (négociation TLS) et améliorer la latence lors des échanges entre serveur web et client.

Cela consiste à disposer d’un serveur web Nginx compilé exprès et accompagné d’une version spéciale de la bibliothèque OpenSSL avec le support de Quic. (Nous ferons bientôt un article de blog séparé sur ce sujet) Il faut bien entendu ajuster la configuration du Nginx pour activer ce protocole, et le pare-feu du serveur pour autoriser le port 443 en UDP.

Après le live, nous avons mesuré le nombre de requêtes HTTP/1.1, HTTP/2.0 et HTTP/3.0 sur le Peertube, et les statistiques sont :

Côté Peertube : HTTP/3.0 à 41%, HTTP/2.0 à 51%, HTTP/1.1 à 8%.
Côté Cluster S3 : HTTP/3.0 à 61%, HTTP/2.0 à 31%, HTTP/1.1 à 8%.

On constate donc que la grand majorité des navigateurs gère bien au moins HTTP/2 et une bonne moitié au moins a le support de HTTP/3 d’actif. On pense qu’un plus grand nombre supporte réellement HTTP/3, mais il peut y avoir plusieurs facteurs bloquants : un réseau d’entreprise bloqué en UDP/443, ou des problèmes d’en-tête alt-svc non transmis dans certaines situations.

Tech: S3 & Minio pour Peertube

Ensuite, nous craignions que la bande passante du serveur ne suffise pas (celui que nous avions étant sur un port de switch limité à 1Gbps). La vidéo étant servie en Full-HD à environ 2Mbps, nous ne pourrions servir que 500 internautes avec une telle bande passante… Or, depuis sa version 5 sortie récemment, Peertube permet de stocker les morceaux de vidéos d’un live non pas sur le serveur localement, mais sur un « serveur de stockages par blocs » (block storage en Anglais) utilisant le protocole S3 inventé par Amazon, et disponible en logiciel libre depuis bien longtemps. Octopuce disposant d’un cluster de serveur S3 équipé d’assez de bande passante, nous avons donc configuré le Peertube de AuPoste pour qu’il utilise cette nouvelle fonction.

Le protocole S3 utilisé pour le stockage des vidéos et des bouts de live de Peertube existe en plusieurs versions. La dernier (s3v4) divise le stockage en « buckets », chaque bucket étant adressé par un sous-domaine distinct du domaine du cluster S3. Ainsi, si le cluster S3 d’Octopuce est visible à l’adresse https://s3-1.octopuce.fr, le bucket de davduf sera à l’adresse https://davduf.s3-1.octopuce.fr.

Or, le logiciel Minio que l’on utilise sur nos serveurs pour ce faire ne gère pas ce mode de fonctionnement par défaut : il s’attend à ce que l’on adresse le bucket à l’adresse https://s3-1.octopuce.fr/davduf/ Il a donc fallu que nous reconfigurions le cluster pour utiliser ce mode de fonctionnement « par DNS » plutôt que « par PATH ».

Cette fonction est disponible dans minio mais très mal documentée : pour l’utiliser, il faut :

pointer tous les sous-domaines de son domaine principal S3 sur le cluster : (mettre toutes les IPv4 et IPv6 du cluster)
s3-1 IN A 185.34.32.232 *.s3-1 IN A 185.34.32.232
disposer d’un certificat TLS wildcard (par exemple par Letsencrypt) pour ce domaine sur tous les nœuds du cluster :
certbot certonly --manual --manual-auth-hook acmedns-auth.py --preferred-challenges dns -d s3-1.octopuce.fr -d '*.s3-1.octopuce.fr'
configurer nginx pour qu’il accepte des connexions destinées à tous les sous-domaines : (extrait de conf)
server_name s3-1.octopuce.fr *.s3-1.octopuce.fr; location / { proxy_set_header Host $http_host; }
configurer minio pour qu’il « sache » qu’il est sous le domaine s3-1.octopuce.fr et qu’il doit donc activer le mode « fqdn » de son serveur : (ici dans /etc/default/minio )
MINIO_DOMAIN="s3-1.octopuce.fr"notez que la directive minio_domain est différente de minio_server_url, la première étant mal sinon pas documentée…

Une fois cela fait, et le cluster minio redémarré (… oui c’est dommage…) on pourra utiliser ce cluster S3 avec Peertube

Ensuite, il faut configurer le cluster S3 pour fournir les fichiers de ce bucket via HTTPS de manière publique, par exemple avec une configuration nginx toute simple faisant proxy vers le cluster S3 sur le bon bucket. Le domaine associé, qui est public, sera dans la configuration base_url ci-dessous. Grace à cela, Peertube déléguera le service des fichiers vidéos et bouts de live à ce cluster, et ne les servira plus lui-même, assurant la bande passante.

Pour configurer Peertube pour du « remote storage », il faut modifier le fichier config/production.yaml ainsi :

object_storage:
  enabled: true
  endpoint: 's3-1.octopuce.fr' # 's3.amazonaws.com' or 's3.fr-par.scw.cloud' for example
  region: 'dc2-f3'
...
  credentials:
    access_key_id: 'un login valable'
    secret_access_key: 'votre clé secrète'
...
  streaming_playlists:
    bucket_name: 'davduf'
    prefix: 'streaming-playlists/'
    # Base url for object URL generation, scheme and host will be replaced by this URL
    # Useful when you want to use a CDN/external proxy
    base_url: 'https://davduf.s3.octopuce.fr'
  # Same settings but for webtorrent videos
  videos:
    bucket_name: 'davduf'
    prefix: 'videos/'
    base_url: 'https://davduf.s3.octopuce.fr'

Notez la différence dans la configuration entre l’url « endpoint » du S3, où Peertube enverra (via une requête HTTPS PUT) les bouts de vidéos, et l’url du « base_url » que Peertube donnera aux internautes, où ils pourront publiquement accéder aux contenus (les fichiers .TS vidéo)

Une fois cela fait, on redémarre Peertube, et on teste ;)

côté performance du serveur Peertube, nous avions déjà une configuration Nginx permettant de servir de nombreux internautes, majoritairement à l’aide des directives suivantes :

worker_processes 12;
worker_rlimit_nofile 250000;
events {
	worker_connections 2048;
	multi_accept on;
}

Tech: observabilité via Collectd / Graphite / Grafana

Afin de pouvoir « voir » ce qu’il se passe pendant le live, nous avons déployé les sondes de collecte d’informations temporelles (time-series data) habituelles d’un serveur d’Octopuce. Utilisant les logiciels Collectd, Graphite, Grafana, nous avons des statistiques de consommation de CPU, RAM, Disque, Réseau, pour la VM concernée et pour les 3 nœuds du cluster S3.

Côté Peertube, ce logiciel permet de disposer de statistiques temporelles spécifiques via OpenTelemetry, fournissant un ensemble de mesures sur le nombre de visiteurs, de live, de vidéos, leurs nombre de visites, les ressources consommées par Peertube etc. Nous avons mis à disposition ces informations à Chocobozzz & Framasoft, afin qu’ils puissent avoir les statistiques souhaitées de leur côté, via le protocole utilisé par Prometheus.

un exemple de graphique montrant l’état d’un serveur sur une période donnée.

Le live, les résultats

Alors ? Que s’est-il donc passé durant le live ?

la CPU de Brassens au moment de l’arrivée massive d’internautes…

Premier boulet : le blog ;)

Première constatation : des internautes qui venaient sur le lien https://auposte.fr/peertube-live/ ont parfois reçu une page 502 au lieu de la page souhaitée. Quel rapport avec Peertube ? Aucun ;) c’est le WordPress de au-poste qui n’a pas tenu la charge faute d’un système de cache adéquat. Cela n’a rien à voir mais mériterait d’être corrigé…

Faire fonctionner un WordPress avec beaucoup de visiteurs est difficile : avoir un système de cache qui fait qu’une page peut être servie avec très peu de calcul nécessite un système de « cache » : soit côté WordPress avec une extension adhoc comme wpSuperCache, soit avec un cache côté serveur comme Varnish (mais l’usage d’un cookie par le site de davduf empêche ce genre de cache de fonctionner…)

Côté Peertube : CPU

Pendant le live, le Peertube s’est très bien comporté : nous n’avons pas déploré de problème majeur de diffusion de la vidéo. Les internautes étaient nombreux : 300 au tout début du live, entre 400 et 410 rapidement, jusqu’à la fin ou le nombre de connecté est lentement descendu jusqu’à 350 personnes à 12h30. C’est donc un bon test.

On voit ci-dessus la CPU et la bande passante consommée par la VM Peertube :

On voit la montée en charge de la CPU de 10h30 à 10h40, ou un pic est atteint à 10h40, heure de début du live.
Ce pic de 10h40 correspond aux transcodeurs de la vidéo live, qui prennent le flux d’origine et en font plusieurs versions : ici du 1080p, 720p & 240p. On a découvert après le live que David avait envoyé du 720p, donc Peertube n’a fait que le transcodage 720p et 240p !
La CPU baisse ensuite lentement, proportionnellement au nombre de visiteurs.
Le gros pâté de 12h50 à 13h18 correspond, après la fin du live, au transcodage à grande vitesse de la vidéo pour mettre à disposition les différents formats en VOD. On ignorera donc ces valeurs pour notre mesure de la CPU par visiteur.
La bande passante réseau est tout de même importante, si on prend en compte le fait que les morceaux de vidéo live servis aux internautes ne passent pas par là. En dehors des uploads vers le cluster S3, Il s’agit donc exclusivement de flux HTTPS de pages web !
Les FFMPEG lancés par Peertube sont en mode « nice » (en gros ils laissent la CPU aux autres s’ils en ont besoin). Si c’est une bonne idée lorsque Peertube souhaite transcoder une vidéo envoyée plus tôt, c’est une mauvaise idée pour du live : on souhaite que ffmpeg dispose de la CPU nécessaire pour transcoder le live, sinon, le live risque de planter ! Nous feront remonter ce bug à Peertube s’il n’est pas déjà connu.

Le graphique ci-dessous montre uniquement la période du live lui-même. La petite barre verticale bleue indique l’heure à laquelle le P2P du live a été activé, et on ne constate que peu ou pas d’influence sur la consommation de ressource du Peertube lui-même.

Côté Octopuce, on a déduit la statistique suivante :

Pour servir 1 Live transcodé en en 720p + 240p il faut compter 2% d’une machine à 66 threads, soit environ 1.5 threads de processeur moderne. Ce type de ressource est donc à la portée de beaucoup de petites machines (souvent 4C/8T) mais cela ne permet de gérer qu’un seul live en même temps : si vous souhaitez pouvoir faire 2 live en même temps, il faudra doubler cette CPU ! etc.
La consommation de CPU de Peertube est vraiment faible en dehors de cela : pour servir toutes ces pages, Peertube prenait 7% des 66 threads, dont 1.5% par le système de chat à lui seul. Compter donc 4 threads pour servir 400 personnes en live.
Le système de chat développé par John utilise une AppImage faisant tourner Prosody, logiciel libre de chat via le protocole XMPP bien connu. Ce système étant hélas pour l’instant « mono thread » il a saturé à 100% de CPU pendant presque tout le live, prenant donc 1 thread de processeur à lui tout seul. Merci à Cyprien de l’équipe d’Octopuce de s’en être rendu compte et de nous l’avoir remonté !

Côté Peertube : Bande Passante & Nginx

Allons voir les logs du serveur Nginx du Peertube pendant le temps du live :

Un premier problème que l’on a trouvé est la présence de nombreuses pages servies avec une réponse « 502 » signifiant un problème côté serveur. entre 200 et 900 par minute !

Nous avons trouvé le coupable : le websocket du plugin de livechat. L’erreur telle que remontée par Nginx étant :

2022/12/30 10:36:56 [error] 147137#147137: *57081 upstream prematurely closed connection while reading response header from upstream, client: <IP>, server: video.davduf.net, request: "GET /plugins/livechat/6.0.0/ws/xmpp-websocket HTTP/1.1", upstream: "http://127.0.0.1:9006/plugins/livechat/6.0.0/ws/xmpp-websocket", host: "video.davduf.net"

Seul indice supplémentaire : nous avons ce message en nombre similaire dans les logs de Peertube :

[video.davduf.net:443 peertube-plugin-livechat] 2022-12-30 11:08:04.722 info: Got a close event for the websocket proxy

Peut-être qu’une configuration nginx spécifique pour le plugin de chat mériterait d’être mise en place pour conserver ouvert le websocket ?

Nous nous sommes quand même posé la question : mais qu’est-ce qui prend 100Mbps de bande passante sur le serveur web ? Cela nous paraissait gros… nous avons donc sorti des statistiques sur 1H (de 10h50 à 11h50) des hits par URI et leur taille totale servie en Mo :

awk '{print $7 " " $10}' /tmp/log | /root/sum.php 15
13194 /plugins/livechat/6.0.0/ws/xmpp-websocket
274 /plugins/livechat/6.0.0/static/conversejs/converse.min.js
120 /plugins/livechat/6.0.0/static/conversejs/converse.min.js.map
107 /client/fr-FR/main.3f1de96c17edc7ce.js
67 /tracker/socket
62 /client/standalone/videos/video-embed.ff5a7a08f7c54735b7fe.bundle.js
60 /videos/watch/85de4a47-669c-441e-a355-2a7cc9793571
57 /client/en-US/main.3f1de96c17edc7ce.js.map
51 /client/fr-FR/main.3f1de96c17edc7ce.js.map
49 /client/standalone/videos/538.66cb162a9effd6e6be56.chunk.js
48 /lazy-static/previews/91ac65eb-f28d-4d4f-9692-dcf3d3116470.jpg
44 /client/fr-FR/5474.a421789c05c17b8f.js
43 /plugins/livechat/6.0.0/static/conversejs/converse.min.css
40 /client/fr-FR/SourceSans3VF-Roman.ttf.1befb5b37992491d.woff2
31 /plugins/livechat/6.0.0/static/conversejs/emojis.js
Total: 14968 Mo

Sur cette période, la bande passante en sortie du Peertube est de 59 Mbps. ces statistiques n’expliquent que 33Mbps (14968 megabytes * 8 bitperbyte / 3600 secondesperhour = 33)

<aparté> : Une partie de la bande passante reste inexpliquée… On a imaginé que cela comprend le trafic du Peertube envoyant les chunks (morceaux) de vidéos au serveur S3 (mais cela ne devrait pas dépasser les 10Mbps). Il se peut aussi qu’une partie non négligeable du trafic du Peertube soit du aux websockets qui sont difficiles à loguer dans Nginx (ils ne sont logués qu’à la déconnexion). Enfin, nous avons découvert après coup que les visites des fichiers statiques (donc les vidéos passées) ne sont pas loguées par Nginx par défaut sur la configuration recommandée par Peertube … Nous n’avons donc pas le trafic (potentiellement important) de ces flux là… Cependant, la vidéo du live étant servie par notre cluster S3, les visites sur les vidéos passées de ce Peertube nous intéressent peu… </aparté>

Ce que l’on remarque tout de suite : la grande majorité de cette bande passante consiste en les échanges sur le websocket du chat : 88% du trafic web est représenté par les échanges de messages de chat ! (ce dernier utilisant le protocole xmpp, réputé très bavard, ce n’est pas très étonnant…)

Donc en dehors du système de chat (qui prend en gros 30Mbps pour 400 personnes en chat) et des uploads des vidéos vers le cluster S3 (qui prends en gros 2Mbps pour du 1080p et 500Kbps pour du 240p etc.) un Peertube, hors flux vidéo, va consommer environ 3Mbps pour 400 personnes connectées à un live.

Côté cluster S3, bande passante surtout

Côté cluster S3, on voit ici un des 3 nœuds du cluster. Si on regarde les autres graphes, on a à peu près la même bande passante : le site https://davduf.s3.octopuce.fr, qui servait les morceaux (chunks .TS) de vidéos et les playlists .m3u8 HLS ayant les 3 Adresses IPv4 et IPv6 flottantes du cluster d’installées dans le DNS.

Pour information, ce cluster sert aussi les contenus statiques de piaille.fr, la nouvelle instance Mastodon lancée par Thibault et Benjamin d’Octopuce. Cette instance fait 18Mbps de manière stable. On peut donc enlever 18 aux valeurs lues sur le graphe. On fera par ailleurs x3 pour mesurer la bande passante des 3 nœuds du cluster.

Ce que l’on voit tout de suite c’est que le live prend beaucoup de bande passante : servir 1800 Mbps pour un serveur, c’est une belle charge. Cela ne nécessite pas forcément une grosse machine (ces nœuds S3 ont 6 core et 16G de RAM) mais cela nécessite une bonne bande passante stable et fiable, si on veut pouvoir servir tous ces Go !

Donc, dans la phase à 400 visiteurs du live sans peer-to-peer activé (donc après 10h39 mais avant la barre bleue de 11h14) on voit environ 1500Mbps sur les 3 nœuds, soit 3.75Mbps par client.

À 11h, Chocobozz nous a écrit pour signaler que le P2P semblait inactif et Octopuce lui donnait accès SSH au serveur pour qu’il aille voir pourquoi. Après modification d’une valeur en base et un message du genre « c’est un bug, il sera corrigé dans la prochaine version de Peertube » (quelle plaisir ce logiciel libre <3 !) le Peer-to-peer du live s’est donc mis à marcher (à droite de la barre bleue). A partir de là, la bande passante consommée baisse rapidement, pour se stabiliser vers 200Mbps, soit 600Mbps pour 350 clients, soit 1.7Mbps par client avec P2P actif. On peut penser que c’est faible comme baisse, on pourrait espérer que le Peer-to-peer fasse baisser la bande passante de beaucoup plus. Mais le paramétrage de Peertube étant posé sur un délai « moyen », soit d’environ 30secondes entre le live et sa diffusion sur les navigateurs, il n’y a que peu de temps pour échanger les morceaux de vidéo. C’est donc déjà pas mal !

Pour celles et ceux qu’une telle bande passante inquiète, sachez qu’il existe des services commerciaux permettant de faire du S3 facilement, et le coût n’est pas si élevé : chez Scaleway.com, par exemple, le streaming d’une vidéo de 3H de live à 400 personnes avec P2P activé coûterai dans les 5,5€HT. C’est facile à mettre en place et pas cher. Reste que nous n’avons pas testé si les public website du système S3 de Scaleway tenaient les 600 Mbps … une question à leur poser.

Les petits bugs du Chat

Dernier point à évoquer : le système de chat de John Livingston nous a donné quelques sueurs : lorsque beaucoup de personnes envoyaient des message en même temps, cela pouvait saturer la CPU des navigateurs des visiteurs, rendant la vidéo saccadée. On voit aussi que cela prend pas mal de CPU sur le serveur (1 thread entier, sûrement plus si Prosody était multi-threadé) et pas mal de bande passante. Enfin, on a constaté qu’il manquait quelques fonctions de modérations et sécurité (éviter les messages trop longs, redondants, ou certains pseudos permettant une usurpation d’identité)

L’avantage d’utiliser ce système étant qu’il est possible de contribuer en aidant John Livingston à le développer, ou en finançant son temps pour cela !

Conclusion

La conclusion principale de ce test de charge est que le système de live de Peertube marche bien, très bien et qu’on peut se reposer sur lui fermement si l’on souhaite diffuser des vidéos en live à un grand nombre de personnes. Avec l’aide d’un système de cluster S3 de diffusion publique, on peut probablement atteindre un nombre de visiteurs important (~10 000) sans le moindre souci (tant que l’hébergeur a la bande passante pour). Le système peer-to-peer de Peertube permet de diviser au moins par 2 la bande passante requise, rendant ce système plus économique pour les réseaux et hébergeurs. Enfin, la mise à disposition de greffons pour Peertube comme celui de Chat développé par John permet de fournir des services similaires aux plateformes propriétaires comme Twitch (possédée par Amazon rappelons-le).

Peertube est donc un excellent logiciel libre de grande qualité, de grande stabilité, à la maintenance sur le temps long facilité par sa documentation et la qualité de son intégration. Nous recommandons son usage pour toutes vos diffusions vidéos, sa compatibilité avec tous les systèmes informatiques habituels (pc, tablettes, téléphones) étant totale.

Test de charge d’un Peertube en Live avec Auposte