Delen via

Algemene prestatieproblemen met Azure Front Door oplossen

  • Artikel

Prestatieproblemen kunnen afkomstig zijn uit verschillende mogelijke gebieden: de Azure Front Door-service, de oorsprong, de aanvragende client of het pad tussen een van deze hops. Deze gids voor probleemoplossing helpt u te bepalen welke hop langs het gegevenspad waarschijnlijk de hoofdmap van een probleem is en hoe u het probleem kunt oplossen.

Controleren op bekende problemen

Controleer voordat u begint op bekende problemen op:

  • Het Azure Front Door-platform.
  • Internetproviders (ISP's) in het pad.
  • De aanvragende client kan verbinding maken en gegevens ophalen.

Scenario 1: De oorsprong onderzoeken

Als een van de oorspronkelijke servers traag is, verloopt de eerste aanvraag voor een object via Azure Front Door traag. Als de content niet in de cache wordt opgeslagen op het Azure Front Door-aanwezigheidspunt (POP), worden aanvragen doorgestuurd naar de oorsprong. Het ophalen vanuit de oorsprong ontkent het voordeel van de nabijheid en lokale levering van de POP aan de aanvragende client en is in plaats daarvan afhankelijk van de prestaties van de oorsprong.

Scenario 1: Omgevingsinformatie nodig

  • Azure Front Door-eindpuntnaam
    • Hostnaam van het eindpunt
    • Aangepast eindpuntdomein (indien van toepassing)
    • Oorsprong hostnaam
  • Volledige URL van het betrokken bestand

Scenario 1: Stappen voor probleemoplossing

  1. Controleer de antwoordheaders van de betreffende aanvraag.

    Gebruik de volgende curl voorbeelden in Bash om antwoordheaders te controleren. U kunt ook de ontwikkelhulpprogramma's van uw browser gebruiken door de F12-toets te selecteren. Selecteer het tabblad Netwerken, selecteer het relevante bestand dat u wilt onderzoeken en selecteer vervolgens het tabblad Kopteksten. Als het bestand ontbreekt, laadt u de pagina opnieuw met de ontwikkelhulpprogramma's geopend.

    Het eerste antwoord moet een x-cache header met een TCP_MISS of CONFIG_NOCACHE waarde hebben. De Azure Front Door POP stuurt aanvragen met deze waarde door naar de oorsprong. De oorsprong verzendt het retourverkeer op datzelfde pad naar de aanvragende client.

    Hier volgt een voorbeeld met 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

    Hier volgt een voorbeeld met 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. Ga door met aanvragen voor het eindpunt totdat de header x-cache een waarde TCP_HIT heeft.

    Als u in eerste instantie hebt gezien CONFIG_NOCACHE, wordt caching niet ingeschakeld in de routeconfiguratie. In dit geval ziet TCP_HITu het niet.

  3. Als het prestatieprobleem is opgelost, is het probleem gebaseerd op de snelheid van de oorsprong en niet op de prestaties van Azure Front Door. De eigenaar moet de cache-instellingen van Azure Front Door of de oorsprong aanpakken om de prestaties te verbeteren.

    Als het probleem zich blijft voordoen, kan de bron de client zijn die de content of de Azure Front Door-service aanvraagt. Ga naar Scenario 2 om de bron op te sporen.

Scenario 2: Een enkele client of locatie (bijvoorbeeld een internetprovider) is traag

Een enkele client of locatie kan traag zijn als er een slechte netwerkroute is tussen de aanvragende client en de Azure Front Door POP. U moet een slechte route uitsluiten omdat deze van invloed is op de afstand tot de POP, waardoor het nabijheidsvoordeel van Azure Front Door POP wordt verwijderd.

Hoge latentie of lage bandbreedte kan het gevolg zijn van een probleem met een internetprovider, als u een virtueel particulier netwerk (VPN) gebruikt of deel uitmaakt van een verspreid bedrijfsnetwerk. Een bedrijfsnetwerk kan al het verkeer via een centraal, extern punt uitvoeren.

Scenario 2: Omgevingsinformatie vereist

  • Azure Front Door-eindpuntnaam
    • Hostnaam van het eindpunt
    • Aangepast eindpuntdomein (indien van toepassing)
    • Oorsprong hostnaam
  • Volledige URL van het betrokken bestand
  • Clientgegevens aanvragen
    • Client-IP aanvragen
    • Clientlocatie aanvragen
    • Clientpad aanvragen naar de Azure-omgeving (meestal geïdentificeerd met tracert, pathping of een vergelijkbaar hulpprogramma)

Scenario 2: Stappen voor probleemoplossing

  1. Als u het pad naar de POP wilt controleren, gebruikt u pathping of een vergelijkbaar hulpprogramma voor 500 pakketten om de netwerkroute te controleren.

    Pathping heeft maximaal 250 query's. Als u wilt testen op 500, voert u de volgende query twee keer uit:

    pathping /q 250 <Full URL of Affected File>

  2. Bepaal of het verkeer een pad neemt waarmee tijd of reizen naar een verre regio wordt toegevoegd.

    Zoek naar IP-, plaats- of regiocodes die geen redelijke route nemen op basis van uw geografie (bijvoorbeeld verkeer in Europa wordt doorgestuurd naar de Verenigde Staten) of die een overmatig aantal hops hebben.

  3. Als u het aanvragen van clientinstellingen wilt uitsluiten, test u vanuit een andere aanvragende client in dezelfde regio.

  4. Als u extra hops of externe regio's identificeert, is het probleem met de client die toegang heeft tot de Azure Front Door POP en niet met de Azure Front Door-service zelf. De connectiviteit of VPN-provider moet hops tussen eindpunten adresseren.

    Als u geen extra hops of externe regio's identificeert en de content vanuit de cache wordt geleverd (x-cache: TCP_HIT), ligt het probleem bij de Azure Front Door-service. Mogelijk moet u een ondersteuningsaanvraag maken. Neem een verwijzing op naar dit artikel voor probleemoplossing en de stappen die u hebt uitgevoerd.

Notitie

Wanneer de inhoud wordt geleverd vanaf de oorsprong (x-cache: TCP_MISS), raadpleegt u Scenario 1 eerder in dit artikel.

Scenario 3: Een website wordt langzaam geladen

In sommige scenario's is er geen probleem met één bestand, maar zijn de prestaties van een hele webpagina (met Azure Front Door-proxy) onvoldoende. Een hulpprogramma voor webpaginaprestaties toont slechte siteprestaties in vergelijking met een webpagina buiten Azure Front Door.

Een webpagina bestaat vaak uit veel bestanden. Een website profiteert alleen van Azure Front Door als Azure Front Door elk bestand op een webpagina aanbiedt. U moet Azure Front Door configureren om het voordeel te maximaliseren.

Kijk een naar het volgende voorbeeld:

  • Oorsprong: origin.contoso.com
  • Aangepast Azure Front Door-domein: contoso.com
  • Pagina die u probeert te laden: https://contoso.com

Wanneer de pagina wordt geladen, roept het eerste bestand in de map "/" bestanden aan, waarmee de pagina wordt gebouwd. Dit zijn afbeeldingen, JavaScript, tekstbestanden en meer. Als deze bestanden niet worden aangeroepen via de hostnaam van Azure Front Door (contoso.com), gebruikt de pagina geen Azure Front Door. Dus als een van de bestanden die de website aanvraagt http://www.images.fabrikam.com/businessimage.jpg is, profiteert het bestand niet van het gebruik van Azure Front Door. In plaats daarvan vraagt de browser op de aanvragende client het bestand rechtstreeks vanaf de server images.fabrikam.com aan.

Diagram van meerdere bestanden van verschillende herkomst voor een enkele website en hoe deze configuratie van invloed is op de prestaties van Azure Front Door.

Scenario 3: Omgevingsinformatie nodig

  • Azure Front Door-eindpuntnaam
    • Hostnaam van het eindpunt
    • Aangepast eindpuntdomein (indien van toepassing)
    • Oorsprong hostnaam
    • Geografische locatie van de oorsprong
  • Volledige URL van de betreffende webpagina
  • Hulpprogramma en metrische gegevens die de prestaties meten

Scenario 3: Problemen oplossen

  1. Bekijk de metrische gegevens die de tragere prestaties tonen.

    Belangrijk

    Microsoft kan niet zien wat er wordt gemeten door hulpprogramma's waarvan deze geen eigenaar is.

  2. Open de Azure Front Door-webpagina in een browser en open vervolgens de ontwikkelhulpprogramma's door de F12-toets te selecteren.

    U kunt de ontwikkelhulpprogramma's in uw browser gebruiken om de bron te bepalen van de bestanden die worden geleverd. Als u de aanvraag-URL in de ontwikkelhulpprogramma's wilt weergeven, selecteert u het tabblad Netwerken, selecteert u het bestand dat u wilt onderzoeken en selecteert u vervolgens Algemeen. Als het bestand ontbreekt, laadt u de pagina opnieuw met geopende ontwikkelhulpprogramma's.

  3. Noteer de bron of de aanvraag-URL van de bestanden.

  4. Bepaal welke bestanden gebruikmaken van de hostnaam van Azure Front Door en welke bestanden dat niet doen.

    In het voorgaande voorbeeld is https://www.contoso.com/productimage1.jpgeen installatiekopie die wordt gehost in Azure Front Door. Een installatiekopie die niet wordt gehost in Azure Front Door, zou http://www.images.fabrikam.com/businessimage.jpg zijn.

  5. Test de prestaties van het bestand dat Azure Front Door bedient, de oorsprong en (indien van toepassing) de testwebpagina.

    Als de webpagina voor oorsprong of testen wordt geleverd vanuit een geografische regio die zich dichter bij het hulpprogramma bevindt dat testprestaties uitvoert, moet u mogelijk een hulpprogramma gebruiken of een client in een andere regio aanvragen om het nabijheidsvoordeel van Azure Front Door POP te onderzoeken.

    Belangrijk

    Bestanden die buiten de Azure Front Door-hostnaam worden geleverd, profiteren er niet van. Mogelijk moet u de webpagina opnieuw ontwerpen om dit te doen.

    Als bestanden zijn bedoeld om in de cache te worden opgeslagen, moet u ervoor zorgen dat u bestanden met de antwoordheader x-cache: TCP_HIT test.

  6. Actie ondernemen op basis van de verzamelde gegevens:

    • Als de verzamelde gegevens laten zien dat bestanden worden uitgegeven van servers buiten de hostnaam van Azure Front Door, werkt Azure Front Door zoals verwacht.

      Het langzaam laden van websites vereist mogelijk een wijziging in het webpaginaontwerp. Voor hulp bij het optimaliseren van uw website voor het gebruik van Azure Front Door, neemt u contact op met uw websiteontwerpteam of met Microsoft-oplossingsproviders.

      Notitie

      Het probleem van het langzaam laden van websites kan tijd in beslag nemen om te controleren, op basis van de complexiteit van het ontwerp van een website en de instructies voor het aanroepen van bestanden.

    • Als de verzamelde gegevens laten zien dat de laadprestaties van de bestanden beter zijn in Azure Front Door in vergelijking met de oorspronkelijke of testsite, werkt Azure Front Door zoals verwacht. De oorzaak van het probleem kan afzonderlijke clientaanvragen zijn. In dat geval raadpleegt u Scenario 1 eerder in dit artikel.

    • Als de verzamelde gegevens laten zien dat de prestaties van Azure Front Door niet beter zijn, moet u waarschijnlijk een ondersteuningsaanvraag indienen voor verder onderzoek. Neem een verwijzing op naar dit artikel voor probleemoplossing en de stappen die u hebt uitgevoerd.