Lors de nos différents projets, nous avons été confrontés à de nombreuses configurations réseaux chez nos clients. Celles-ci ont évidemment eu un impact sur l’expérience utilisateur final

Afin de partager avec vous les résultats de notre recherche, nous avons reproduit certains cas et évalué leur impact sur les performances des services d’Office 365.

Comme d’habitude, nous utilisons nos sondes déployées à travers le monde pour mesurer l’expérience utilisateur.

Pour ce test, nous avons à déployé 10 Robots Users installés dans différents sites (Azure, Bangalore, Boston, Nice, Philadelphie) avec différentes configurations (avec ou sans proxy, connexion passant par le siège en Europe ou non, etc.).

Configuration du meilleur point d’entrée et de sortie (Egress point)

Le point le plus important à considérer lors du déploiement de votre Office 365 est votre point d’entrée. La manière dont vous accédez à votre tenant et la configuration du point d’accès sont extrêmement importantes.

En faisant un simple ping vers Office 365, depuis n’importe quelle région où vous vous trouvez, vous verrez les résultats de latence spécifique à votre région. C’est un test intéressant mais cela n’aide pas vraiment quand il s’agit de comprendre ce qui se passe du côté de l’utilisateur final.

Voyons comment détecter des problèmes de configuration avec des mesures réelles sur l’expérience de l’utilisateur final.

Les premiers résultats de test que nous analysons ici sont l’expérience utilisateur « Nouveau Rendez-vous » (Create a meeting)

Création de meeting Office 365

Ici, les résultats affirment que si nous analysons tout simplement la tâche »ouverture de boîte email », tout semble bien fonctionner. Cependant, nous pourrions être en mesure de voir des résultats différents si nous examinons d’autres actions qu’un utilisateur peut réaliser.

Faisons alors le tour de ces autres actions pour savoir si « l’ouverture d’une boîte email » est une mesure suffisante pour tester les connexions au niveau du tenant.

En haut, nous voyons un graphique linéaire qui compare les performances dans le temps de chaque robot-utilisateur.

En bas à gauche, nous avons la liste de tous les robots-utilisateur (ici, les utilisateurs actifs sont un chez Microsoft Azure, un à Bangalore, deux à Boston et un à Nice). Dans la partie inférieure, quelques statistiques ont été mise en avant pour mesurer la sévérité des problèmes de connexion.

Le tableau carré en bas à droite compare le temps moyen passé par chaque robot-utilisateur pour effectuer l’action sélectionnée (créer une réunion dans notre cas).

La performance du robot-user de Bangalore (noir) qui tente d’accéder au tenant européen n’est pas aussi bonne que celle des robots-user aux États-Unis (rouge et jaune) qui tentent d’accéder au tenant européen. Le plus performant est le robot-utilisateur situé en Europe accédant au tenant européen (vert) et, bien sûr, le dernier Robot qui tourne Azure et qui se connecte à Office 365.

Pour être plus clair, la performance varie selon le moment où vos utilisateurs se connectent et le lieu où se trouve leur point d’entrée.

Concentrons nous sur ce test depuis une localisation avec 2 routes différents afin de confirmer l’exactitude de nos résultats.

Depuis Boston, nous avons effectué 2 types de test en utilisant des boîtes aux lettres dédiées.

Un robot-utilisateur tente d’accéder à un tenant européen et le second accède au tenant basé aux États-Unis.

Nous recevons une latence de 450 ms entre Boston et le tenant européen contre 390 ms lorsque Boston essaie de joindre un tenant américain.

Nous enregistrons donc une différence de latence de 20%, tout simplement parce que le robot-utilisateur est basé aux États-Unis, puis à partir du point d’entrée américain, il a traversé les réseaux Microsoft en Europe, là où se trouve la boîte aux lettres.

Vous devez absolument tenir compte de ces paramètres lorsque vous organisez votre tenant et votre point d’entrée dans le monde entier. Limiter la distance entre les utilisateurs et leur boîte email est toujours une bonne chose pour améliorer les performances au niveau de l’utilisateur final.

Observons maintenant un exemple typique chez nos clients de grande tailles

Connexion via le siège

Expériences

Comme la plupart des sociétés dans le monde, nous avons organisé nos tests pour simuler une entreprise possédant plusieurs succursales. Dans notre exemple, nous avons effectué 2 différents tests à partir de la même localisation: tous deux situés à Philadelphie et se sont connectés à un tenant en Europe.

Ainsi, vous pouvez imaginer une société dont le siège mondial est situé en Europe et chacune de ses succursales se connectent au siège puis se connectent à Internet depuis différentes parties du monde.

Cette situation s’est produite auprès de plusieurs clients que nous avons audité et qui ont subit des problèmes de performance: la limitation d’Internet au sein de l’entreprise et la connexion vers l’extérieur de l’entreprise.

Pour vous montrer l’impact, nous avons reproduit la situation avec un robot-user se connectant directement à Internet à Philadelphie afin de se connecter au réseau Microsoft aux États-Unis. Il a ensuite traversé directement l’océan sur leur réseau.

Nous avons fait en sorte que le deuxième robot-utilisateur se connecte au siège et se connecte ensuite à Internet pour accéder au tenant européen.

Vous pouvez voir sur le tableau de bord que nous considérons également les bonds (hops) avec comme postulat que moins il y a de bonds, meilleure est la connexion.

Ici, le robot-user à Philadelphie se connecte au point de terminaison Microsoft aux États-Unis et voyage sur le réseau Microsoft, et il a parcouru 26 bonds (hops).

Celui qui se connecte au siège en Europe puis se connecte à Internet enregistre 15 bonds. Cela pourrait nous amener à penser que ce dernier était plus rapide que les premiers robots-utilisateur (RU2).

Mais ce n’était pas nécessairement le cas. Regardons les résultats.

 

Résultats

En vert, nous voyons le robot-utilisateur 1, situé au siège en Europe, configuré pour bloquer la connexion à Internet.

En noir, le robot-utilisateur 2 à Philadelphie est configuré pour accéder à Internet dès que possible.

Au milieu, nous pouvons voir les résultats dans des graphiques linéaires, action par action. Dans le graphique carré, nous pouvons également voir comment chaque carré représente la performance moyenne d’une action d’un robot. Ce type de graphique permet une comparaison visuelle facile des performances du robot-utilisateur.

En bas, nous pouvons voir deux graphiques montrant le nombre de fois une action donnée a atteint le seuil de performance acceptable.

Nous avons défini qu’un seuil acceptable serait de trois secondes pour les fonctions recherche de disponibilité et de création de rendez-vous. Ces trois secondes proviennent de nos observations chez nos clients en rapprochant les mesures de performance avec les tickets ouverts par les utilisateurs finaux.

En travaillant avec nos clients et leurs environnements, il apparaît que si les utilisateurs doivent à plusieurs reprises attendre 3 secondes pour une simple recherche de disponibilité ou pour créer une réunion, ils commenceront à ouvrir des tickets en raison d’une perte de patience.

L’analyse des données

Tout d’abord, nous avons regardé l’ouverture de boîte email. Mais cela n’a pas vraiment d’importance, car les plaintes et les tickets de support proviennent principalement des actions réelles que les utilisateurs effectuent, telles que la recherche de disponibilité / création de réunion.

La recherche de disponibilité montre ce que l’utilisateur final observe lorsqu’il y a un problème de performance, il voit les barres d’attentes se remplir à chaque fois qu’ils tentent de créer une réunion. C’est particulièrement vrai lorsqu’il y a plusieurs participants.

Aller de Philadelphie au siège avec 15 bonds ajoute en moyenne 1 seconde sur la recherche de disponibilité. Pendant deux jours, la recherche de disponibilité a dépassé 16 fois le seuil d’alerte

Passer directement de Philadelphie à Internet, en utilisant un point d’entrée Microsoft aux États-Unis, offre une latence moyenne d’environ 0,6 seconde, soit 40% plus rapide. Le nombre de fois où la performance était en dehors des seuils dans l’exemple était de 8 fois.

Cela a eu un impact sur la fonction « créer un rendez-vous », où nous avons pu constater une différence de 50 à 60% sur l’expérience utilisateur.

Ces données sont très importantes lorsque vous examinez ce que vous pouvez faire pour améliorer les performances. Ce scénario montre à quel point il est facile d’améliorer les performances avec une simple correction de la configuration du réseau.

Microsoft disposera toujours du meilleur réseau et le choix d’une configuration optimale a un impact important sur l’expérience utilisateur.

 

Vérifiez nos résultats

Afin de garantir que ces résultats n’aient pas été faussés par un mauvais réseau local au niveau du siège, nous avons ajouté un autre robot-utilisateur qui opère depuis le siège en Europe et qui se connecte au tenant.

Vous pouvez voir les nouveaux résultats en rouge:

De toute évidence, c’est clairement le plus performant ce qui confirme que le réseau du siège n’a pas de problème. Mais nous constatons également que les performances ne sont pas si éloignées du robot de Philadelphie qui se connecte à Internet aux États-Unis (le robot du siège social est environ 15% plus rapide).

La seule action qui a une différence est l’ouverture de boîte email, mais encore une fois ce n’est pas vraiment le test le plus critique pour le ressentit utilisateur.

La conclusion qu’on peut en tirer est que la meilleure chose à faire est d’atteindre le réseau de Microsoft le plus rapidement possible.

Sortir vers Internet en vue d’accéder à un tenant situé géographiquement près de chez vous et amener vos paquets chez Microsoft aussi vite que possible n’est pas toujours une bonne solution.

Nous avons en effet vu que la configuration de l’itinéraire entre vos sites et le centre de données Office 365 ont un impact réel sur les performances de l’utilisateur final.

Travailler sur ce sujet est une première étape importante pour améliorer les performances globales des services Microsoft Cloud.