La surveillance des performances de vos applications WebRTC peut considérablement améliorer votre expérience utilisateur

La dernière chose qu'une entreprise souhaite est d'être connue comme un service peu fiable et peu performant, surtout s'il existe des solutions similaires à quelques clics de souris. Il est donc indispensable d'être conscient des performances d'une application WebRTC ou de toute autre solution logicielle pour éviter les problèmes à l'avenir. Une solution peut être développée par des personnes expérimentées et testée avant sa sortie, mais cela ne signifie pas pour autant que les dégradations de performances n'apparaîtront jamais. Reconnaître les problèmes tôt et agir en conséquence peut aider beaucoup à améliorer l'expérience des utilisateurs.

Imaginez que votre application d'appel vidéo rencontre des problèmes en cas de perte de paquets . La perte de paquets peut provoquer un son saccadé, une vidéo figée ou des images vidéo manquantes, ce qui rend difficile pour les utilisateurs de comprendre ce qui se dit ou de voir ce qui se passe pendant l'appel. Une perte de paquets élevée peut également rendre difficile l'établissement et le maintien d'une connexion par l'application, ce qui entraîne la perte d'appels ou de conversations vidéo. Si vous et votre équipe n'avez pas subi de perte de paquets lors du développement de l'application, il existe un moyen de découvrir qu'il y a un problème : un client déçu peut vous informer de son expérience désagréable. Bien sûr, il serait bien préférable de se renseigner sur le problème et de le résoudre avant que les utilisateurs ne le rencontrent.

C'est pourquoi la surveillance est une pratique si bénéfique - observer régulièrement les performances et le comportement du produit au fil du temps vous permet de réagir rapidement à tout problème qui survient et de maintenir un service fiable et performant. Cela améliore non seulement l'expérience utilisateur, entraînant une satisfaction et une fidélité accrues des clients, mais donne également à votre entreprise un avantage concurrentiel sur le marché.

Bénéficie d'un suivi régulier des applications :

• Recevoir rapidement des notifications sur les problèmes. En configurant les notifications d'échec de surveillance et de test, vous serez alerté des problèmes en temps réel et pourrez prendre des mesures en temps opportun avant que les utilisateurs n'aient une mauvaise expérience.
• La surveillance fournit des rapports détaillés qui peuvent vous aider à identifier la cause première des échecs et à identifier les domaines de votre application qui doivent être améliorés.
• Économise beaucoup de temps. La surveillance est un processus automatisé, ce qui signifie que vous pouvez créer la solution une seule fois et la laisser fonctionner avec peu ou pas de maintenance.
• Confiance que votre solution fonctionne bien. Lorsque la surveillance est en place, vous pouvez avoir la tranquillité d'esprit que votre application est vérifiée régulièrement et fonctionne correctement si vous n'avez reçu aucune notification récemment.
• Possibilité de comparer les performances dans le temps. Lorsque votre configuration de surveillance exécute régulièrement les mêmes tests et effectue des mesures, vous pouvez ensuite agréger les données et voir comment les performances ont évolué au fil du temps.

Fonctionnement de la surveillance des applications WebRTC avec Loadero

Loadero est un outil de test de charge et de performance capable de simuler le comportement réel des utilisateurs et l'interaction avec les sites Web en utilisant des technologies d'automatisation Web, telles que "Javascript + Nightwatch", "Java + TestUI" ou "Python + Py-TestUI". Parallèlement à cela, il vous fournit toutes les statistiques WebRTC et machine nécessaires telles que le FPS, le débit binaire, la gigue, le temps d'aller-retour et autres, qui ont été recueillies pendant le test et sont capables de les affirmer.

Comme la surveillance nécessite une observation constante, par exemple, des tests constants dans notre cas, nous aurions également besoin de déclencher périodiquement des tests. À cette fin, un pipeline CI/CD est un excellent choix car il est flexible et n'est pas compliqué à configurer pour notre tâche. Outre l'exécution périodique des tests, le pipeline peut également être utilisé pour automatiser les tests après chaque déploiement afin de s'assurer que les performances sont bonnes.

Afin de commencer à surveiller votre solution WebRTC avec Loadero, une configuration composée de 3 parties est requise :

1. Un test Loadero qui évaluera les performances de votre application WebRTC. Vous pouvez trouver un exemple ici .
2. Un script qui utilise l'API Loadero pour lancer le test, obtenir les résultats et notifier l'échec.
3. Un pipeline CI/CD pour exécuter automatiquement le script.

Mise en place d'un test pour la configuration de la surveillance

Commençons par configurer le test Loadero pour notre exemple de configuration de surveillance. Si vous avez déjà un test dans Loadero, qui peut être lancé pour vérifier certaines des mesures de performance, vous pouvez ignorer cette partie et passer à la partie sur le lancement de tests via le pipeline. Si c'est la première fois que vous travaillez sur un test dans Loadero, un guide complet étape par étape sur la façon de créer un test dans Loadero peut être trouvé dans cet article de blog . Si vous avez déjà un test de performance WebRTC dans un autre service, voyez comment vous pouvez migrer votre test vers Loadero ici . Dans notre cas, nous aurons un test « Javascript + Nightwatch ». Le scénario sera un appel individuel d'une minute à Jitsi .

Dans le test, deux participants rejoindront un appel et y resteront pendant une minute, prenant quelques captures d'écran à mi-chemin pour une vérification de connexion supplémentaire.

Les participants se connecteront depuis l'Oregon américain, utiliseront la dernière version de Google Chrome (109v au moment de la rédaction de ce blog) et utiliseront la vidéo + l'audio par défaut pour simuler le signal de sortie.

Nous utiliserons également les assertions post-exécution de Loadero. Ils vous permettent de spécifier les critères de «réussite» pour WebRTC et/ou les métriques de la machine dans votre test, comme «si FPS moyen ≥ 10, alors réussite». Une fois l'exécution terminée, les résultats d'assertion sont calculés automatiquement pour chaque participant afin de vérifier si les valeurs données répondent aux critères de réussite. Si l'assertion a échoué pour un participant, le statut de ce participant dans le rapport de résultats sera également « Échec ».

Avec les assertions, nous évaluerons le débit binaire et les paquets entrants et sortants pour l'audio et la vidéo ainsi que les FPS.

La configuration de notre test ressemblerait à ceci :

• Mode test : 'Test de performances'
• Stratégie d'incrément : 'Participant linéaire'
• Intervalle de démarrage : 1 s
• Délai d'attente du participant : 5 min

Dans cet exemple, nous avons un script de test Loadero écrit en Javascript + Nightwatch, mais la même chose peut être faite avec Java + TestUI ou Python + Py-TestUI.

 client => { client // Open the page .url(`https://meet.jit.si/LoaderoTests`) // Wait until the username field is visible // And enter the username .waitForElementVisible('[placeholder]', 30 * 1000) .sendKeys('[placeholder]', 'User') // Wait until the "Join" button is visible // And join the call by pressing the button .waitForElementVisible('[aria-label="Join meeting"]', 10 * 1000) .click('[aria-label="Join meeting"]') // Another thing you can do is to take screenshots during the test // Which could help you to identify the cause of a failure // And give visual feeback about the test run .takeScreenshot('pre_call_screenshot.png') // Stay in the call for half a minute .pause(30 * 1000) // Take a mid-call screenshot .takeScreenshot('mid_call_screenshot.png') // Stay in the call for another half a minute .pause(30 * 1000) // Take a post-call screenshot .takeScreenshot('post_call_screenshot.png'); }

Définition des attentes de performances WebRTC

Chaque application WebRTC est différente et aura des performances légèrement différentes. Ici, nous visons à définir les seuils où nous voulons être immédiatement avertis si les attentes de performance ne sont pas satisfaites, même si cela se produit pendant la nuit. Pour ce faire, nous utiliserons un ensemble d'assertions post-exécution de Loadero pour les métriques WebRTC, ce qui fera échouer l'ensemble du test si les valeurs des métriques de performance WebRTC ne sont pas aussi bonnes que nous aimerions les voir. Par conséquent, les valeurs cibles ne doivent pas être définies sur des marges étroites, mais nous devons permettre que les tests soient parfois légèrement pires que nous le souhaiterions idéalement, mais toujours dans des performances raisonnables. Les valeurs que nous avons définies ici sont des exemples et vous souhaiterez peut-être les ajuster en fonction des spécificités de l'application (par exemple, si vous privilégiez une fréquence d'images élevée sur la bande passante du réseau, vous souhaiterez peut-être augmenter la fréquence d'images minimale que vous souhaitez voir et diminuer les limites de débit). Comme point de départ, vous pouvez utiliser la liste des assertions ci-dessous :

Voici la liste des assertions et leurs valeurs que nous avons définies pour cet exemple de test :

• Affirmer que la vidéo contient au moins 10 images par seconde pendant plus de 75 % de la durée de l'appel dans les flux vidéo entrants et sortants. De plus, vérifiez que les fluctuations de la fréquence d'images sont faibles, pas plus de 2 images par seconde, en définissant une assertion sur l'écart type :

  • webrtc/video/fps/out/25th >= 10

  • webrtc/video/fps/in/25th >= 10

  • webrtc/video/fps/out/stddev < 2

  • webrtc/video/fps/in/stddev < 2

    
    

• Vérifier les valeurs des paquets envoyés par seconde est important pour s'assurer que les performances sont optimales. L'envoi de trop de paquets par seconde introduira plus de surcharge, mais en envoyant plus de paquets, la gigue peut être plus faible car le délai entre les paquets est plus petit. Un bon équilibre doit être trouvé et il peut différer d'une application à l'autre. Dans cet exemple, nous allons vérifier si le nombre de paquets envoyés par seconde est compris entre 40 et 100 :

  • webrtc/audio/packets/out/avg > 40/sec

  • webrtc/video/packets/out/avg > 100/sec

  • webrtc/audio/packets/in/avg > 40/sec

  • webrtc/video/packets/in/avg > 100/sec

    
    

• Le débit binaire indique la quantité de données envoyées par seconde. Généralement, plus le média envoyé est de haute qualité, plus le débit binaire est élevé. Cependant, certaines applications tenteront de minimiser le débit binaire pour mieux fonctionner sur de mauvais réseaux et consommer moins de données. Avec ces assertions, nous vérifions que la consommation de données ne dépasse pas les valeurs définies de 25 kbit/s pour l'audio entrant et sortant et de 1 000 kbit/s pour la vidéo entrante et sortante pendant 95 % de la durée du test :
  • webrtc/audio/bitrate/out/95th <= 25 kbit/sec
  • webrtc/video/bitrate/out/95th <= 1000 kbit/sec
  • webrtc/audio/bitrate/in/95th <= 25 kbit/sec
  • webrtc/video/bitrate/in/95th <= 1000 kbit/sec

Configuration des participants au test et exécution du test

Enfin, nous devons configurer les participants au test. Nous allons avoir 1 groupe de participants qui aura 2 participants avec la même configuration qui rejoindront l'appel. La configuration des participants est la suivante :

• Titre – 'Participant'
• Compter - 2
• Unités de calcul : G2
• Navigateur - 'Dernier Google Chrome'
• Emplacement - 'US West - Oregon'
• Réseau - 'Paramètres réseau par défaut'
• Flux audio - 'Flux audio par défaut'
• Flux vidéo - "Flux vidéo par défaut"

Conseil : si vous souhaitez que plusieurs participants aient exactement la même configuration, augmentez la valeur Count dans le menu de configuration. Afin de gagner du temps, nous vous suggérons de créer des participants individuellement uniquement dans le cas où ils doivent avoir des configurations différentes.

Pour la configuration de test, ce serait tout. Mais comme nous avons l'intention d'exécuter notre test régulièrement, avant de procéder à la configuration de notre configuration de surveillance, exécutez le test et vérifiez que le script n'est pas défectueux en vérifiant les journaux Selenium et les captures d'écran que les participants ont prises pendant l'exécution du test. Si c'est la première fois que vous lancez un test dans Loadero, ou si vous n'êtes tout simplement pas sûr qu'il ait été correctement configuré, utilisez ce billet de blog pour vérifier si votre test est prêt à être lancé .

Comme mentionné précédemment, les participants peuvent toujours échouer si les assertions de métrique WebRTC échouent et le taux de réussite peut ne pas être de 100 %. Cela s'est produit pour notre test aussi.

Cela ne signifie pas nécessairement que le test est défectueux, seulement que l'application ne répond pas aux critères d'assertion que vous avez définis. Mais si votre test a échoué pour une autre raison que les assertions définies, ce billet de blog explique quelques façons de déboguer votre test.

Les assertions que nous définissons ne sont qu'une base de référence générale non adaptée à l'application que nous testons. Vous pouvez utiliser la liste et commencer par ces valeurs, mais l'application que vous testez peut différer et les résultats des métriques peuvent également être très différents.

Astuce : Une bonne façon de définir vos propres assertions serait de faire 5 tests, d'examiner les mesures des participants et d'évaluer des objectifs raisonnables.

Définir ces assertions et analyser les résultats pour découvrir pourquoi les assertions ont échoué est une tâche complexe en soi, nous n'entrerons donc pas trop dans les détails à ce sujet dans ce billet de blog. De plus, le fait que notre exemple de test ait échoué en raison d'un échec d'assertion simule exactement le cas dont nous avons besoin, lorsqu'un test a échoué et qu'une notification concernant l'échec est envoyée, nous allons donc le laisser tel quel. Si les journaux Selenium montrent que vous n'avez rencontré aucune erreur et que les captures d'écran confirment que toutes les actions nécessaires ont été prises, le test est toujours bon.

Lancer régulièrement des tests depuis le pipeline

Notre équipe a déjà préparé quelques articles de blog sur la façon d'intégrer des tests dans votre pipeline de développement : en utilisant JS et le client Python de Loadero . Nous allons donc nous appuyer ici sur eux. Pour notre configuration, nous utiliserons ce qui est suggéré dans le billet de blog qui utilise Python, GitHub et son implémentation CI/CD - Workflows avec le client Loadero Python.

Remarque : certaines informations peuvent être ignorées. Pour des instructions détaillées, reportez-vous à l' article original du blog Loadero Python .

Pour notre flux de travail, nous aurons besoin de :

• Un référentiel GitHub
• Un fichier YAML qui définit le workflow
• Un script Python pour exécuter le test Loadero et rapporter les résultats

Créez un nouveau référentiel sur GitHub ou utilisez-en un existant.

Dans votre référentiel, dans le répertoire .github/workflows créez un fichier notify-on-fail.yml . C'est le fichier qui va contenir des instructions sur la façon de configurer l'environnement et de lancer le test Loadero.

Commençons à définir le workflow en spécifiant les déclencheurs dans le notify-on-fail.yml .

 on: schedule: - cron: '0 9-18 * * *' workflow_dispatch:

schedule vous permet de déclencher un workflow à une heure planifiée. C'est donc l'endroit où vous définissez la fréquence des exécutions de test. Dans notre exemple, nous avons défini le calendrier pour exécuter le test toutes les heures de 9h à 18h, car c'est l'heure à laquelle l'équipe est la plus susceptible de pouvoir réagir en cas d'échec. Au cas où vous auriez besoin d'exécuter des tests tout au long du cycle jour-nuit, vous préférerez peut-être les exécuter toutes les 4 heures environ. Ainsi, vous surveillez l'application même lorsque personne n'est réveillé. Faites attention, cet schedule utilise une syntaxe spécifique plus sur laquelle vous pouvez en savoir plus ici .

Astuce : Lors du réglage de la fréquence des tests, considérez que la période entre les tests doit être plus longue que la durée du test, car vos tests peuvent interférer les uns avec les autres.

Le deuxième déclencheur - workflow_dispatch - permet de déclencher le pipeline manuellement via l'application Web GitHub si nécessaire.

Dans notre section jobs du script, nous spécifions l'environnement et toutes les dépendances que nous utiliserons. Pour notre objectif, la configuration du billet de blog Loadero Python convient parfaitement, alors n'hésitez pas à la copier-coller.

 jobs: notify-on-fail: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: "3.10" - run: pip install loadero-python - run: python run.py env: LOADERO_ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }} LOADERO_PROJECT_ID: ${{ secrets.PROJECT_ID }} LOADERO_TEST_ID: ${{ secrets.TEST_ID }}

Important: faites attention, que dans la ligne - run: python run.py , après le python, nous avons le chemin de votre fichier run.py par rapport à la racine du référentiel. Dans mon cas, la structure du fichier ressemblera à ceci :

Une autre chose à laquelle il faut prêter attention est les informations d'identification. Tout d'abord, vous pouvez trouver l'ID de test et de projet dans Loadero, mais vous aurez également besoin d'un jeton d'accès à l'API de projet - actuellement, les jetons d'accès au projet sont acquis en les demandant à notre équipe d'assistance. Deuxièmement, les informations d'identification sont utilisées comme secrets GitHub Actions. Cela permet de garder votre jeton d'accès Loadero privé. Les secrets peuvent être configurés dans les paramètres du référentiel -> Sécurité -> Secrets et variables -> Actions -> Nouveau secret du référentiel.

Pour les instructions détaillées étape par étape sur les secrets, reportez-vous au billet de blog mentionné précédemment.

Ainsi, la configuration du flux de travail pour l'instant devrait ressembler à ceci :

 name: Notify about failing tests in Loadero on: schedule: - cron: '0 9-18 * * *' workflow_dispatch: jobs: notify-on-fail: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: "3.10" - run: pip install loadero-python - run: python run.py env: LOADERO_ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }} LOADERO_PROJECT_ID: ${{ secrets.PROJECT_ID }} LOADERO_TEST_ID: ${{ secrets.TEST_ID }}

Ajoutons maintenant à notre configuration le script Python pour interagir avec Loadero. Encore une fois, le script du blog Loadero Python est un excellent point de départ, nous allons donc l'utiliser et le modifier plus tard pour nos besoins.

 import os from loadero_python.api_client import APIClient from loadero_python.resources.test import Test project_id = os.environ.get("LOADERO_PROJECT_ID", None) access_token = os.environ.get("LOADERO_ACCESS_TOKEN", None) test_id = os.environ.get("LOADERO_TEST_ID", None) if project_id is None or access_token is None or test_id is None: raise Exception( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) APIClient( project_id=project_id, access_token=access_token, ) run = Test(test_id=test_id).launch().poll() print(run) for result in run.results()[0]: print(result) if run.params.success_rate != 1: raise Exception("Test failed")

Envoi de notifications sur les tests échoués

Il est maintenant temps de modifier notre script Python afin d'implémenter nos notifications. Dans cet exemple, l'alerte sera envoyée à un canal Discord. Bien que la façon dont vous implémentez les notifications soit totalement facultative, car cela dépend de vos préférences personnelles.

Mettons à jour notre fichier Python en important la bibliothèque de requêtes, les classes ResultStatus et AssertStatus .

 import requests import os from loadero_python.api_client import APIClient from loadero_python.resources.test import Test from loadero_python.resources.classificator import ResultStatus, AssertStatus

Ainsi que la mise à jour de notre fichier YAML pour installer la bibliothèque de requêtes.

 - run: pip install loadero-python - run: pip install requests - run: python run.py

Si le pipeline est mal configuré et que la valeur de l'une des informations d'identification est None, nous devons en informer notre canal Discord en envoyant une requête POST avec le message d'erreur.

 missing_credentials_message = ( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) def send_notification(message): requests.post( "https://discordapp.com/api/webhooks/{id}", data={"content": message}, ) if project_id is None or access_token is None or test_id is None: send_notification(missing_credentials_message) raise Exception(missing_credentials_message)

Si le test échoue, nous aimerions en connaître la raison. Ici, nous ajoutons la vérification du participant. Si un participant échoue, nous envoyons le message d'erreur avec la structure suivante :

• Nom des participants
• Résultat sélénium
• Statut
• Échec du chemin de l'assertion
• État d'exécution

De plus, nous devrions nous débarrasser de l'exception du script initial, car elle est excessive ici

 run_failure_message = "" for result in run.results()[0]: result.params.run_id = run.params.run_id result.read() if ( result.params.selenium_result.value != ResultStatus.RS_PASS or result.params.status.value != ResultStatus.RS_PASS ): run_failure_message += ( f"{result.params.participant_details.participant_name}:\n" f"-Selenium result: {result.params.selenium_result.value}\n" f"-Participant status: {result.params.status.value}\n" ) if result.params.asserts: run_failure_message += "-Failing asserts:\n" for assertion in result.params.asserts: if assertion.status != AssertStatus.AS_PASS: run_failure_message += f"--{assertion.path.value}\n" run_failure_message += "\n" run_failure_message += f"Run status: {run.params.status.value}" if run.params.success_rate != 1: send_notification(run_failure_message)

Et envoyons également un message pour le test réussi :

 if run.params.success_rate != 1: send_notification(run_failure_message) else: send_notification(f"The {run.params.test_name} test has been finished successfully")

En tant que vérification finale, nous devrions encapsuler l'ensemble de l'appel API dans try-except si la connexion avec l'API Loadero est défectueuse. Le script python final ressemble à ceci :

 import os import requests from loadero_python.api_client import APIClient from loadero_python.resources.test import Test from loadero_python.resources.classificator import ResultStatus, AssertStatus project_id = os.environ.get("LOADERO_PROJECT_ID", None) access_token = os.environ.get("LOADERO_ACCESS_TOKEN", None) test_id = os.environ.get("LOADERO_TEST_ID", None) missing_credentials_message = ( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) def send_notification(message): requests.post( "https://discordapp.com/api/webhooks/{id}", data={"content": message}, ) if project_id is None or access_token is None or test_id is None: send_notification(missing_credentials_message) raise Exception(missing_credentials_message) try: APIClient( project_id=project_id, access_token=access_token, ) run = Test(test_id=test_id).launch().poll() print(run) run_failure_message = "" for result in run.results()[0]: result.params.run_id = run.params.run_id result.read() if ( result.params.selenium_result.value != ResultStatus.RS_PASS or result.params.status.value != ResultStatus.RS_PASS ): run_failure_message += ( f"{result.params.participant_details.participant_name}:\n" f"-Selenium result: {result.params.selenium_result.value}\n" f"-Participant status: {result.params.status.value}\n" ) if result.params.asserts: run_failure_message += "-Failing asserts:\n" for assertion in result.params.asserts: if assertion.status != AssertStatus.AS_PASS: run_failure_message += f"--{assertion.path.value}\n" run_failure_message += "\n" run_failure_message += f"Run status: {run.params.status.value}" if run.params.success_rate != 1: send_notification(run_failure_message) else: send_notification( f"The {run.params.test_name} test has been finished successfully" ) except Exception as err: send_notification(f"Error while running Loadero test: {err}")

Inspecter les résultats de la surveillance WebRTC

Désormais, notre test s'exécute automatiquement toutes les heures de 9h à 18h et évalue si l'application fonctionne comme prévu.

Une fois l'exécution du test terminée, en cas d'échec du test, vous êtes averti de l'échec.

Dans notre cas, le test Jitsi a échoué en raison de FPS et de paquets ne répondant pas à nos critères, ce qui peut être vu dans l'onglet Asserts du résultat du test. Les résultats de l'assertion sont également accessibles pour chaque participant individuellement, de sorte que vous pouvez vérifier si le problème s'est produit pour tous les participants ou seulement pour une partie d'entre eux.

Les valeurs fournies ci-dessus pour les assertions peuvent servir de référence de départ, et il semble que dans notre cas, elles ne correspondent pas aux performances cibles de Jitsi. N'hésitez donc pas à explorer les performances de votre application et les assertions qui correspondent le mieux à votre application, afin de vous assurer que le processus de surveillance est optimal.

Remarque : rien qu'en regardant les assertions de notre test, nous pouvons constater qu'il existe des sections entières qui génèrent des zéros tout au long de l'exécution du test, ce qui a finalement un impact sur les résultats du test.

Conseil : Si votre test a échoué, vous pouvez accéder à l'onglet Statistiques WebRTC, où vous pouvez trouver divers graphiques avec des données et obtenir plus d'informations sur la métrique qui a causé l'échec.

Dans cet article de blog, nous avons fourni un exemple de la façon dont vous pouvez surveiller votre application WebRTC avec l'aide de Loadero et des flux de travail GitHub. Avec l'utilisation de la surveillance, vous êtes mieux équipé pour faire face à tout problème pouvant survenir dans votre application. Il peut également être judicieux de créer d'autres scénarios avec des conditions différentes pour une vue plus globale des performances de l'application. La mise en place d'une telle surveillance peut être une tâche assez complexe. Souhaitez-vous que l'équipe Loadero crée une configuration de surveillance similaire pour vous ? N'hésitez pas à nous contacter à [email protected] et discutons de la manière dont nous pouvons vous aider à surveiller régulièrement et automatiquement votre solution WebRTC.