Performances et passage à l'échelle
Les performances ne sont pas une fin en soi : c’est ce qui rend la sobriété possible. Plus le serveur est efficace, moins il consomme.
Relayer beaucoup de flux, dans beaucoup de salles, sur peu de cœurs, avec une mémoire stable et une latence faible, sans jamais transcoder.
Le verrou technique
Section intitulée « Le verrou technique »Tenir cette charge de façon prévisible : éviter qu’une salle très active ne bloque les autres, garder une mémoire bornée sous charge soutenue, et savoir mesurer honnêtement la capacité réelle.
La démarche
Section intitulée « La démarche »- Relai RTP brut. Les paquets sont réémis sans ré-encodage ; aucun codec vidéo n’est touché.
- Architecture multi-thread. Chaque thread possède son propre socket UDP ;
les participants sont répartis entre les threads par hachage de
(salle, client), ce qui parallélise les poignées de main et le traitement. Voir Architecture du SFU. - Contre-pression maîtrisée. Les files inter-threads sont bornées et leur profondeur est exposée en métrique ; la boucle draine par lots avec un budget de temps, pour éviter qu’une salle chargée ne bloque les autres.
- Appels système groupés pour l’envoi et la réception réseau.
- Profilage mémoire. Un travail au profileur (
perf,bytehound) a permis d’identifier et d’éliminer une croissance mémoire sous charge soutenue ; l’empreinte est désormais stable.
Mesurer honnêtement : le harnais de test de charge
Section intitulée « Mesurer honnêtement : le harnais de test de charge »C’est une contribution à part entière. Plutôt que des chiffres théoriques, nous mesurons la capacité réelle avec un harnais à deux étages :
- Des bots de rejeu rejouent de vrais flux WebRTC, capturés une fois depuis une vraie webcam, sans les ré-encoder. Ils utilisent la même bibliothèque str0m que le serveur : au niveau réseau (DTLS-SRTP, ICE, SCTP, RTP), ils sont indiscernables d’un vrai client, et gèrent le simulcast. Des centaines tiennent sur une seule machine.
- Des témoins navigateurs (de vrais Chromium) sont plongés dans cette charge et mesurent la qualité réellement vécue (images par seconde, gigue, gels, perte audio, latence).
La méthodologie est volontairement conservatrice : les bots émettent à débit constant, sans régulation de leur montant, ce qui impose au serveur une charge supérieure ou égale à celle de vrais clients. Le signal de capacité qui fait foi est l’état du serveur lui-même (CPU par thread, profondeur des files, pertes UDP).
Les résultats
Section intitulée « Les résultats »- Le relai média proprement dit ne pèse que quelques pour cent du processeur.
- L’empreinte mémoire reste stable sous charge soutenue.
- En version beta, une instance de quelques cœurs a soutenu plusieurs centaines de participants simultanés, selon la topologie des salles.
Les mesures se poursuivent à mesure que les optimisations sont consolidées.