Tester Google Meet pour résoudre les problèmes de performances des appels vidéo avec meet.Google.com peut être rapide et efficace grâce à la monitoring des performances du réseau (NPM) et à l’analyse du routage en temps réel, lorsqu’il est intégré au test de l’expérience numérique Google Meet (DEM). Cette approche vous permet de tester Google Meet à partir du contexte, du navigateur et de l’emplacement de l’appelant, et de comprendre si les problèmes de réunion Google proviennent des serveurs multimédias Google Meet, de la connectivité réseau ou de l’appareil des utilisateurs. La réalisation d’un test Google Meet régulier dans les bureaux clés et les lieux de travail à domicile aide le service informatique à optimiser la connectivité et les performances du navigateur afin d’améliorer l’expérience utilisateur numérique des appels Meet pour les employés, les clients et les autres invités.
Transcription vidéo [EN]
Comment résoudre les problèmes de performances de Google Meet
When monitoring performance of collaborative platforms like Google Meet, there are two main aspects to take into account. First, the users have to access the platform itself. They connect to a SaaS application that has to be responsive, and you should be able to understand all transactions.
Next, the users will join an interactive audio-video streaming session. If you want to ensure this session to be of high quality, you must be able to monitor network performance to the media servers.
Let’s focus on the initial transactions first, and in this small example, you can see that 12 people have used the Google Meet platform for a total of nine hours and 42 minutes. These connected mainly from France, from Belgium and from Canada.
Connecting to the Google Meet platform doesn’t mean your browser will only interact with a single server. In fact, there are a lot of different services involved. For example, here you see a server that is delivering static content, and if you want to identify the content navigate to the resource dashboard, and you can identify all the different resources that are being delivered by this content server. For example, an image that corresponds to the Meet logo.
But coming back on the different servers that deliver the Google Meet application, it’s important for you to monitor the respective performance. Here you can see that the average response time for all servers was sometimes degraded. By simply focusing on the specific degradation I can quickly identify the Google Meet sessions that were impacted.
So for example, here, this one was impacted by a slower server response time. Let’s see who was impacted. I can simply focus on this specific Google Meet session, and I can navigate to the user group’s dashboard. In this case, you see two users, one connected on the local ISP Orange in France, the second connected on the Altima Telecom ISP in Canada.
Both users are working from home, and you can identify them. So here my colleagues, Scott and Boris, were in a call for 15 minutes. And by the way, Boris was the most impacted by this server response time on the Orange ISP.
The second aspect to take into account is the network latency from the users to the media servers. These servers manage the real time audio and video streaming. The good news with Google Meet is that each user normally connects to a local media server according to his or her geolocation.
Google recommends to keep the network latency below 100 milliseconds in order to guarantee proper end user experience. It also means that the traffic should reach the Google network backbone as quickly as possible. Ideally, your local ISP should directly peer with Google. Let’s now have a quick look at the real case example.
The graph here shows the streaming traffic network pass between a user located in Paris and a local Google Media server. As you can see, the user first connects to the Orange local ISP, and you see that Orange doesn’t peer directly with a Google backbone network. Instead Orange peers with Telia that finally peers with the Google network.
Where is most of the delay being introduced? By highlighting the delays, you get the answer immediately. You see that most of the delay is introduced within the Google network itself, and is not caused by the two ISPs.
Here the average connectivity performance is five to two milliseconds, far below the recommended value.
Kadiska was designed to monitor the digital experience of SaaS applications and how network routing performance impacts it.
