Sélectionner une page

Le 14 mai 2020 dernier, nous avons fait une expérience publique intéressante : nous avons rassemblé plus de 100 personnes sur un salon BigBlueButton unique, avec 3 personnes qui parlent, 2 en webcam, et tous les autres ayant accès uniquement :

  • à voir les webcam et entendre les audio
  • interdiction de parler
  • accès au chat public

L’instance bigbluebutton tournait en version 2.2.0-5, soit la dernière version, sur une Ubuntu 16.04.6 LTS à jour. Le serveur est une machine avec 2 processeurs AMD EPYC 7351 16-Core Processor soit 32 cores disponibles et 64 threads. Nous avions limité la VM à 42 de ces 64 threads, et 60Go de RAM.

Nous avions pendant tout ce temps une sonde collectd qui collectait le nombre de participant au salon, on notera qu’il y avait entre 2 et 5 salons actifs pendant notre test, ce qui perturbe un peu les stats, mais montre aussi que BBB est capable de tenir d’autres salon pendant qu’on tenait une AG à 167…

La consommation la plus simple est la RAM : elle n’a quasiment pas bougé : les process freeswitch, kurento media server, red5 et java de bigbluebutton n’ont pas bougé ou très peu pendant ce pic de charge (on est passé de 9 à 11G de RAM)

La bande passante réseau a clairement subit un pic proportionnel au nombre de participants. Avec 2 webcam et 3 flux audio mixés pour 150 individus, nous avons atteind les 100Mbps. Notez que dans des situations différentes (comme l’exemple multi-salon en bas de ce post) nous avons déjà dépassé allégrement ces valeurs. La machine pouvant tenir 1Gbps, il y en avait sous le pied !

Notre principale inquiétude était la consommation de CPU de BBB, et notamment de son serveur kurento media server (qui diffuse les webcam) et freeswitch (chargé des flux audio). Freeswitch étant lancé en Nice (étonnant…) on constate que freeswitch prend à lui seul 11 à 17% de la CPU soit 4.5 à 7 threads, et en gros kurento et nodejs prenaient le reste. Nodejs nous a étonné : il s’agit du serveur meteor de l’application HTML5 utilisée par les clients. nodejs/meteor consommait à lui seul 2 threads en permanence, surement du fait du chat à gérer.
Kurento était plus calme, et malgré ses flux réseau importants, il n’avait qu’à faire passer des paquets UDP de webcam, Kurentomedia server prenait entre 1 et 2.5 threads pour ce travail

Dernier point, pour comparaison, nous avions fait quelques jours avant de nombreuses réunions pour un de nos clients (une fédération nationale d’associations) et les stats étaient très différentes :

On voit clairement la différence dans le mode multi-salon : plus de CPU consommé pour moins de participants au total.

Le nombre de participants était élevé (on est monté à 143) mais répartis sur une vingtaine de salons. Au total on avait aussi 78 personnes en visio.

Conséquence de cela : la CPU consommée était bien supérieure, mais égale pour le freeswitch (étonnant, on s’attendait à plus), et supérieure pour Kurento, qui avait de nombreuses webcam à gérer

Le crash final !

En fin de réunion, nous avons tenté quelque chose d’un peu fou : partager le tableau blanc entre les 140 participants restants. Cela a immédiatement et définitivement fait planter meteor côté client ET côté serveur… trop de données à passer sur 140 websockets, et ni nos 2 firefox et chrome de modérateurs ne s’en sont remis, ni le nodejs côté serveur. C’était un bon test et donc un bon conseil : n’allumez pas le bouton « tableau blanc partagé » dans un salon très chargé en participants !

Enfin, le chat à 160 rame un peu, on pensait que cela était du à son historique qui s’est rapidement rempli, mais purger le chat n’a pas changé grand chose : gérer un chat à 160, c’est compliqué, surtout si on veut afficher tous les messages à tout le monde…

Si vous avez d’autres questions à poser sur cette expérimentation, n’hésitez pas à envoyer un message twitter à @octopucefr nous tenterons d’y répondre !