Partager via

Résoudre des problèmes de performance générale avec Azure Front Door

  • Article

Les problèmes de performance peuvent provenir de plusieurs endroits : le service Azure Front Door, l'origine, le client demandeur ou le chemin d'accès entre tous ces tronçons. Ce guide de résolution des problèmes vous aide à identifier le tronçon le plus probable du chemin d’accès aux données qui est à la racine d’un problème et comment résoudre ce problème.

Rechercher des problèmes connus

Avant de commencer, vérifiez qu’il n’y a pas de problème connu sur :

  • La plateforme Azure Front Door.
  • les fournisseurs d’accès à Internet (FAI) sur le chemin d’accès.
  • Capacité du client demandeur à se connecter et à récupérer des données.

Scénario 1 : explorer l’origine

Si l’un des serveurs d’origine est lent, la première requête d’un objet via Azure Front Door est lente. En outre, si le contenu n’est pas mis en cache au point de présence Azure Front Door (POP), les demandes sont transmises à l’origine. Le service à partir de l’origine annule l’avantage de la proximité du POP et de la livraison locale au client demandeur et s’appuie à la place sur les performances de l’origine.

Scénario 1 : informations sur l’environnement nécessaires

  • Nom du point de terminaison d’Azure Front Door
    • Nom d’hôte du point de terminaison
    • Domaine personnalisé du point de terminaison (le cas échéant)
    • Nom d’hôte d’origine
  • URL complet du fichier affecté

Scénario 1 : étapes de résolution des problèmes

  1. Vérifier les en-têtes de réponse de la requête affectée.

    Pour vérifier les en-têtes de réponse, utilisez les exemples curl suivants en Bash. Vous pouvez également utiliser les outils de développement de votre navigateur en appuyant sur la touche F12. Sélectionnez l’onglet Réseau, sélectionnez le fichier à examiner, puis sélectionnez l’onglet En-têtes. Si le fichier est manquant, rechargez la page avec les outils de développement ouverts.

    La réponse initiale doit avoir un en-tête x-cache avec une valeur TCP_MISS ou CONFIG_NOCACHE. Le POP Azure Front Door transmet les demandes avec cette valeur à l’origine. L’origine envoie le trafic de retour sur le même chemin au client demandeur.

    Voici un exemple qui affiche TCP_MISS :

    $ curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:02:09 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170209Z-AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
x-fd-int-roxy-purgeid: 0
x-cache: TCP_MISS
accept-ranges: bytes

    Voici un exemple qui affiche TCP_HIT :

    curl -I https://www.contoso.com/styles.css
HTTP/2 200
date: Wed, 28 Aug 2024 17:04:38 GMT
content-type: text/css
content-length: 2837
last-modified: Thu, 09 May 2024 20:49:36 GMT
etag: "b15-6180b8e9bd897"
vary: Accept-Encoding
x-azure-ref: 20240828T170438Z-BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
x-fd-int-roxy-purgeid: 0
x-cache: TCP_HIT
x-cache-info: L1_T2
accept-ranges: bytes

  2. Poursuivre la requête contre le point de terminaison jusqu’à ce que l’en-tête x-cache ait une valeur TCP_HIT.

    Si vous avez initialement vu CONFIG_NOCACHE, la mise en cache n’est pas activée dans la configuration de l’itinéraire. Dans ce cas, vous ne verrez pas TCP_HIT.

  3. Si le problème de performance est résolu, il est dû à la vitesse de l’origine et non à la performance d’Azure Front Door. Le propriétaire doit modifier les paramètres du cache d’Azure Front Door ou l’origine pour améliorer les performances.

    Si le problème persiste, la source peut être le client qui demande le contenu ou le service Azure Front Door. Passez au scénario 2 pour identifier la source.

Scénario 2 : un client ou un emplacement unique (par exemple, un ISP) est lent

Un client unique ou un emplacement peut être lent en cas d’itinéraire réseau incorrect entre le client demandeur et le POP Azure Front Door. Il convient d’écarter toute mauvaise route car elle affecte la distance par rapport au POP, ce qui supprime l’avantage de proximité du POP Azure Front Door.

Une latence élevée ou une faible largeur de bande peuvent être le résultat d’un problème de fournisseur d’accès à Internet, si vous utilisez un réseau privé virtuel (VPN) ou si vous faites partie d’un réseau d’entreprise dispersé. Un réseau d’entreprise peut faire passer tout le trafic par un point central et distant.

Scénario 2 : informations sur l’environnement nécessaires

  • Nom du point de terminaison d’Azure Front Door
    • Nom d’hôte du point de terminaison
    • Domaine personnalisé du point de terminaison (le cas échéant)
    • Nom d’hôte d’origine
  • URL complet du fichier affecté
  • Demande d’informations client
    • IP du client demandeur
    • Demande de localisation du client
    • Demande du chemin d’accès client à l’environnement Azure (généralement identifié avec tracert, pathping ou un outil similaire)

Scénario 2 : étapes de résolution des problèmes

  1. Pour vérifier le chemin d’accès au POP, utilisez pathping ou un outil similaire pour 500 paquets afin de vérifier l’itinéraire réseau.

    Pathping est limité à 250 requêtes. Pour tester jusqu’à 500, exécutez deux fois la requête suivante :

    pathping /q 250 <Full URL of Affected File>

  2. Déterminez si le trafic emprunte un chemin qui ajouterait du temps ou des déplacements vers une région éloignée.

    Recherchez les codes IP, de ville ou de région qui n’empruntent pas un itinéraire raisonnable en fonction de votre géographie (par exemple, le trafic en Europe est acheminé vers les États-Unis) ou qui présentent un nombre excessif de sauts.

  3. Pour exclure les paramètres du client demandeur, effectuez un test à partir d’un autre client demandeur dans la même région.

  4. Si vous identifiez des tronçons supplémentaires ou des régions éloignées, le problème se situe au niveau du client qui accède au POP Azure Front Door et non au niveau du service Azure Front Door lui-même. Le fournisseur de connectivité ou de VPN doit prendre en compte les tronçons entre les points de terminaison.

    Si vous n’identifiez pas de tronçons supplémentaires ou de régions distantes et le contenu est servi à partir du cache (x-cache: TCP_HIT), le problème se situe au niveau du service Azure Front Door. Il se peut que vous deviez créer une requête d’assistance. Incluez une référence à cet article de dépannage et aux étapes que vous avez suivies.

Remarque

Lorsque le contenu est servi à partir de l’origine (x-cache: TCP_MISS), consultez le scénario 1 plus haut dans cet article.

Scénario 3 : un site web se charge lentement

Dans certains scénarios, un seul fichier ne pose pas de problème, mais les performances de l’ensemble d’une page web (avec proxy Azure Front Door) ne sont pas satisfaisantes. Un outil de performance des pages web montre que les performances du site sont médiocres par rapport à celles d’une page web située en dehors d’Azure Front Door.

Une page web se compose souvent de plusieurs fichiers. Un site web ne bénéficie des avantages d’Azure Front Door que si Azure Front Door sert chaque fichier sur une page web. Vous devez configurer Azure Front Door pour en tirer le meilleur parti.

Prenons l’exemple suivant :

  • Origine : origin.contoso.com
  • Azure Front Door : domaine personnalisé : contoso.com
  • Page que vous essayez de charger : https://contoso.com

Lorsque la page se charge, le fichier initial du répertoire « / » appelle d’autres fichiers qui construisent la page. Ces fichiers sont des images, des fichiers JavaScript, des fichiers texte, etc. Si ces fichiers ne sont pas appelés par le nom d’hôte Azure Front Door (contoso.com), la page n’utilise pas Azure Front Door. Ainsi, si l’un des fichiers demandés par le site web est http://www.images.fabrikam.com/businessimage.jpg, ce fichier ne bénéficie pas de l’utilisation d’Azure Front Door. Au lieu de cela, le navigateur du client requérant demande le fichier directement au serveur images.fabrikam.com.

Diagramme de fichiers multiples, de sources différentes, pour un site web unique et comment cette configuration affecte les performances d'Azure Front Door.

Scénario 3 : informations sur l’environnement nécessaires

  • Nom du point de terminaison d’Azure Front Door
    • Nom d’hôte du point de terminaison
    • Domaine personnalisé du point de terminaison (le cas échéant)
    • Nom d’hôte d’origine
    • Situation géographique de l’origine
  • URL complète de la page web concernée
  • Outil et métrique qui mesure les performances

Scénario 3 : résolution des problèmes

  1. Analyser les indicateurs de performance qui affiche les performances les plus lentes.

    Important

    Microsoft ne peut pas discerner ce qui est mesuré par des outils qui ne lui appartiennent pas.

  2. Ouvrez la page web Azure Front Door dans un navigateur, puis ouvrez les outils de développement en appuyant sur la touche F12.

    Vous pouvez utiliser les outils de développement de votre navigateur pour déterminer la source des fichiers servis. Pour afficher l’URL de requête dans les outils de développement, sélectionnez l’onglet Mise en réseau, sélectionnez le fichier que vous étudiez, puis sélectionnez Général. Si le fichier est manquant, rechargez la page avec les outils de développement ouverts.

  3. Notez la source, ou l’URL de la requête, des fichiers.

  4. Identifier les fichiers qui utilisent le nom d’hôte Azure Front Door et ceux qui ne l’utilisent pas.

    Dans l’exemple précédent, une image hébergée dans Azure Front Door serait https://www.contoso.com/productimage1.jpg. Une image non hébergée dans Azure Front Door serait http://www.images.fabrikam.com/businessimage.jpg.

  5. Testez les performances du fichier servi par Azure Front Door, son origine et (le cas échéant) la page web de test.

    Si la page web d’origine ou de test est servie à partir d’une région géographique plus proche de l’outil qui teste les performances, il se peut que vous deviez utiliser un outil ou un client demandeur dans une autre région pour examiner l’avantage de la proximité du POP Azure Front Door.

    Important

    Tout fichier servi en dehors du nom d'hôte Azure Front Door n'en bénéficiera pas. Pour ce faire, vous devrez peut-être revoir la conception de la page web.

    Si les fichiers sont destinés à être mis en cache, veillez à tester les fichiers qui ont l’en-tête de réponse x-cache: TCP_HIT.

  6. Agissez en fonction des données collectées :

    • Si les données collectées montrent que les fichiers sont émis à partir de serveurs situés en dehors du nom d’hôte d’Azure Front Door, Azure Front Door fonctionne comme prévu.

      Les sites web qui se chargent lentement peuvent nécessiter une modification de la conception de la page web. Pour obtenir de l’aide afin d’optimiser votre site web pour utiliser Azure Front Door, contactez votre équipe de conception de sites web ou les fournisseurs de solutions Microsoft.

      Remarque

      Le problème des sites web qui se chargent lentement peut prendre du temps à analyser, selon la complexité de la conception du site web et des instructions d’appel de fichiers.

    • Si les données collectées montrent que la performance de chargement des fichiers est meilleure sur Azure Front Door par rapport au site d’origine ou de test, Azure Front Door fonctionne comme prévu. La source du problème pourrait être les requêtes individuelles des clients. Dans ce cas, consultez scénario 1 plus haut dans cet article.

    • Si les données collectées montrent que les performances ne sont pas meilleures avec Azure Front Door, il est probable que vous deviez déposer une demande d’assistance pour une enquête plus approfondie. Incluez une référence à cet article de dépannage et aux étapes que vous avez suivies.