Tester la charge de votre serveur

Combien de participants votre serveur tient il, sur votre matériel, avant que la qualité se dégrade ? Vuisio fournit un harnais de test de charge open source (AGPL, dans tools/loadtest-bot) pour le mesurer sur votre propre installation, plutôt que de se fier à des chiffres théoriques.

Le principe

Lancer un vrai navigateur par utilisateur sature la machine de test bien avant le serveur : chaque Chromium encode de la vidéo en temps réel. Le harnais dissocie donc les deux préoccupations.

• Des bots de rejeu légers rejouent de vrais flux WebRTC, capturés une fois depuis une 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.
• Le signal de capacité qui fait foi est l’état du serveur lui-même, lu sur l’endpoint /metrics.

La méthodologie est volontairement conservatrice : les bots émettent à débit constant, sans réguler leur montant, ce qui impose au serveur une charge supérieure ou égale à celle de vrais clients. Le contexte complet est décrit dans Performances et passage à l’échelle.

Ce qu’il vous faut

• Une copie du dépôt et une chaîne Rust : le harnais se compile depuis les sources publiques.

• Le binaire en version release :

  cargo build --release -p vuisio-loadtest-bot

  Lancez toujours le bot en --release. Le build debug est environ cinq fois plus lent et fausse le garde-fou de charge du générateur.

• L’endpoint /metrics activé sur le serveur à tester (jeton VUISIO_METRICS_TOKEN). Voir Supervision.

• De préférence, une machine distincte pour lancer les bots : ne faites pas tourner le générateur sur le serveur que vous mesurez.

1. Obtenir des flux de référence (une seule fois)

Les bots rejouent de vrais flux, capturés une fois puis réutilisés. La sous-commande record démarre un SFU jetable qui sert le client web :

./target/release/loadtest-bot record \
  --out data/capture \
  --webclient <dossier statique du client web>

Ouvrez http://localhost:3000/ dans Chrome, rejoignez avec une webcam, ajoutez au moins deux spectateurs (pour que les trois couches simulcast soient émises), puis arrêtez avec Ctrl-C. Vérifiez la capture :

./target/release/loadtest-bot inspect --dir data/capture

Chaque flux affiche son type, son codec, sa couche (h, m, l), son nombre d’images et d’images clés, et sa durée.

2. Vérifier avec un seul bot

Pointez --base sur l’endpoint HTTP du SFU à tester :

./target/release/loadtest-bot replay \
  --base https://votre-domaine --room test --create-room \
  --reference-dir data/capture --duration 60

Le bot détecte automatiquement le flux à rejouer, négocie le simulcast et journalise le code d’invitation de la salle. Vous pouvez rejoindre cette salle depuis un vrai navigateur avec ce code pour confirmer que le flux se décode.

3. Générer la charge : le swarm

./target/release/loadtest-bot swarm \
  --base https://votre-domaine --reference-dir data/capture \
  --rooms 5 --per-room 8 --speakers-per-room 1 --duration 120

Les paramètres qui comptent :

• --rooms et --per-room : la topologie (nombre de salles, participants par salle). C’est ce que vous augmentez palier par palier.
• --speakers-per-room (défaut 1) : combien de bots par salle portent un vrai niveau audio. 1 est réaliste ; au-delà, tous les bots passent orateurs et la rotation des couches provoque des tempêtes d’images clés qui faussent la mesure.
• --bot-stagger-ms et --room-stagger-ms : espacent les arrivées. La rafale de poignées de main DTLS est le goulet au moment du join ; augmentez ces délais pour de gros paliers.

Le bot journalise le nombre de bots vivants et sa propre charge processeur, qui sert de garde-fou.

4. Lire le résultat

La capacité qui fait foi se lit sur le serveur, via /metrics (voir Supervision). Surveillez :

• vuisio_sfu_thread_cpu_seconds_total{thread} : un thread qui approche un cœur plein signale que le plafond est proche.
• vuisio_cross_thread_queue_depth{thread} : une profondeur qui grimpe durablement signale que le serveur n’absorbe plus la charge. C’est le premier signe, avant la latence ressentie par les participants.
• vuisio_packets_dropped_total : les pertes.

Serveur ou générateur ? Le bot affiche sa propre consommation processeur. Si le générateur sature avant le serveur, le chiffre obtenu n’est pas celui du serveur : vous êtes limités par le générateur. Répartissez alors les bots sur plusieurs machines, ou retenez un plafond local honnête. La capacité de votre serveur est le plus grand palier qui tient pendant que c’est le serveur qui limite.

Pour des chiffres précis de qualité vécue (images par seconde, gels côté participant), rejoignez la charge avec de vrais navigateurs, idéalement depuis une autre machine que le générateur, sinon les témoins et les bots se disputent le processeur.

Précautions

• Testez hors production ou hors heures ouvrées : un test de charge sature volontairement le serveur.
• Un serveur derrière nginx applique une limite de débit sur la création de salles (/room/start) par adresse IP. Pour de gros paliers, testez contre un endpoint dédié ou relevez temporairement cette limite, puis remettez la.
• Un grand nombre de connexions simultanées demande un plafond de descripteurs de fichiers (nofile) élevé côté serveur.