Condividi tramite

Risolvere i problemi generali relativi alle prestazioni con Frontdoor di Azure

  • Articolo

I problemi di prestazioni possono avere origine in diverse aree potenziali: il servizio Frontdoor di Azure, l'origine, il client richiedente o il percorso tra uno di questi hop. Questa guida alla risoluzione dei problemi consente di identificare quale hop lungo il percorso dati è probabilmente la radice di un problema e come risolvere il problema.

Verificare la presenza di problemi noti

Prima di iniziare, verificare la presenza di eventuali problemi noti in:

Scenario 1: Analizzare l'origine

Se uno dei server di origine è lento, la prima richiesta di un oggetto tramite Frontdoor di Azure è lenta. Inoltre, se il contenuto non viene memorizzato nella cache del punto di presenza (POP) di Frontdoor di Azure, le richieste vengono inoltrate all'origine. Il servizio dall'origine nega il vantaggio della prossimità e della consegna locale del POP al client richiedente e si basa invece sulle prestazioni dell'origine.

Scenario 1: Informazioni sull'ambiente necessarie

  • Nome dell'endpoint di Frontdoor di Azure
    • Nome host dell'endpoint
    • Dominio personalizzato dell'endpoint (se applicabile)
    • Nome host origine
  • URL completo del file interessato

Scenario 1: Procedura di risoluzione dei problemi

  1. Controllare le intestazioni di risposta dalla richiesta interessata.

    Per controllare le intestazioni di risposta, usare gli esempi seguenti curl in Bash. Inoltre è possibile utilizzare gli strumenti di sviluppo del browser selezionando il tasto F12. Selezionare la scheda Rete, selezionare il file pertinente da analizzare e poi selezionare la scheda Intestazioni. Se il file non è presente, ricaricare la pagina con gli strumenti di sviluppo aperti.

    La risposta iniziale deve avere un'intestazione x-cache con un TCP_MISS valore o CONFIG_NOCACHE . Il POP di Frontdoor di Azure inoltra le richieste con questo valore all'origine. L'origine invia il traffico restituito nello stesso percorso al client richiedente.

    Di seguito un esempio che mostra 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

    Di seguito un esempio che mostra 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. Continuare a richiedere l'endpoint fino a quando l'intestazione x-cache non possiede un valore TCP_HIT.

    Se inizialmente è stato visualizzato CONFIG_NOCACHE, la memorizzazione nella cache non è abilitata nella configurazione della route. In questo caso, non verrà visualizzato TCP_HIT.

  3. Se il problema di prestazioni viene risolto, il problema aveva sede nella velocità dell'origine e non sulle prestazioni di Frontdoor di Azure. Il proprietario deve soddisfare le impostazioni della cache di Frontdoor di Azure o l'origine per migliorare le prestazioni.

    Se il problema persiste, l'origine potrebbe essere il client che richiede il contenuto o il servizio Frontdoor di Azure. Passare allo scenario 2 per identificare l'origine.

Scenario 2: un singolo client o posizione (ad esempio, un ISP) è lento

Un singolo client o posizione possono essere lenti se è presente una route di rete non valida tra il client richiedente e il POP di Frontdoor di Azure. È consigliabile escludere qualsiasi route non valida perché influisce sulla distanza dal POP, che rimuove il vantaggio di prossimità del POP di Frontdoor di Azure.

Latenza elevata o bandwidth bassa può essere il risultato di un problema ISP, se si usa una rete privata virtuale (VPN) o si fa parte di una rete aziendale distribuita. Una rete aziendale può eseguire tutto il traffico attraverso un punto centrale e remoto.

Scenario 2: Informazioni sull'ambiente necessarie

  • Nome dell'endpoint di Frontdoor di Azure
    • Nome host dell'endpoint
    • Dominio personalizzato dell'endpoint (se applicabile)
    • Nome host origine
  • URL completo del file interessato
  • Richiesta di informazioni sul client
    • Richiesta IP del client
    • Richiesta del percorso client
    • Richiesta del percorso client all'ambiente Azure (in genere identificato con tracert, pathping o uno strumento simile)

Scenario 2: Procedura di risoluzione dei problemi

  1. Per controllare il percorso del POP, usare pathping o uno strumento simile per 500 pacchetti per controllare la route di rete.

    Pathping presenta un massimo di 250 query. Per eseguire il test su 500, eseguire la query seguente due volte:

    pathping /q 250 <Full URL of Affected File>

  2. Determinare se il traffico sta prendendo un percorso che aggiunge tempo o viaggi a un'area distante.

    Cercare i codici IP, città o area che non accettano un percorso ragionevole in base alla propria area geografica (ad esempio, il traffico in Europa viene instradato agli Stati Uniti) o che hanno un numero eccessivo di hop.

  3. Per escludere la richiesta di impostazioni client, eseguire il test da un client richiedente diverso nella stessa area.

  4. Se si identificano hop aggiuntivi o aree remote, il problema riguarda il client che accede al POP di Frontdoor di Azure e non con il servizio Frontdoor di Azure. Il provider di connettività o VPN deve gestire gli hop tra gli endpoint.

    Se non si identificano hop aggiuntivi o aree remote e il contenuto viene servito dalla cache (x-cache: TCP_HIT), il problema riguarda il servizio Frontdoor di Azure. Potrebbe essere necessario creare una richiesta di supporto. Includere un riferimento a questo articolo sulla risoluzione dei problemi e i passaggi eseguiti.

Nota

Quando il contenuto viene fornito dall'origine (x-cache: TCP_MISS), vedere Scenario 1 in precedenza in questo articolo.

Scenario 3: Un sito Web viene caricato lentamente

In alcuni scenari non esiste alcun problema con un singolo file, ma non sono soddisfacenti le prestazioni di un'intera pagina Web (proxy di Frontdoor di Azure). Uno strumento per le prestazioni delle pagine Web mostra prestazioni del sito scarse rispetto a una pagina Web all'esterno di Frontdoor di Azure.

Una pagina Web è spesso costituita da molti file. Un sito Web offre vantaggi da Frontdoor di Azure solo se Frontdoor di Azure gestisce ogni file in una pagina Web. È necessario configurare Frontdoor di Azure per ottimizzare il vantaggio.

Si consideri l'esempio seguente:

  • Origine: origin.contoso.com
  • Dominio personalizzato di Frontdoor di Azure: contoso.com
  • Pagina che si sta provando a caricare: https://contoso.com

Quando la pagina viene caricata, il file iniziale nella directory "/" chiama altri file, che compilano la pagina. Questi file sono immagini, JavaScript, file di testo e altro ancora. Se questi file non vengono chiamati tramite il nome host di Frontdoor di Azure (contoso.com), la pagina non usa Frontdoor di Azure. Pertanto, se uno dei file che il sito Web richiede è http://www.images.fabrikam.com/businessimage.jpg, il file non trae vantaggio dall'uso di Frontdoor di Azure. Invece, il browser sul client richiedente richiede il file direttamente dal server images.fabrikam.com.

Diagramma di più file con origine diversa per un singolo sito Web e di come questa configurazione influisce sulle prestazioni di Frontdoor di Azure.

Scenario 3: Informazioni sull'ambiente necessarie

  • Nome dell'endpoint di Frontdoor di Azure
    • Nome host dell'endpoint
    • Dominio personalizzato dell'endpoint (se applicabile)
    • Nome host origine
    • Posizione geografica dell'origine
  • URL completo della pagina Web interessata
  • Strumento e metrica che misurano le prestazioni

Scenario 3: Risoluzione dei problemi

  1. Esaminare la metrica che mostra le prestazioni più lente.

    Importante

    Microsoft non è in grado di distinguere ciò che viene misurato dagli strumenti che non possiede.

  2. Aprire la pagina Web di Frontdoor di Azure in un browser e quindi aprire gli strumenti di sviluppo selezionando la chiave F12.

    È possibile usare gli strumenti di sviluppo nel browser per determinare l'origine dei file gestiti. Per visualizzare l'URL della richiesta negli strumenti di sviluppo, selezionare la scheda Rete, selezionare il file che si sta esaminando e quindi selezionare Generale. Se il file non è presente, ricaricare la pagina con gli strumenti di sviluppo aperti.

  3. Prendere nota dell'origine o dell'URL della richiesta dei file.

  4. Identificare i file che usano il nome host di Frontdoor di Azure e quali file non lo fanno.

    Nell'esempio precedente, un'immagine ospitata in Frontdoor di Azure è https://www.contoso.com/productimage1.jpg. Un'immagine non ospitata in Frontdoor di Azure sarebbe http://www.images.fabrikam.com/businessimage.jpg.

  5. Testare le prestazioni del file usato da Frontdoor di Azure, la relativa origine e (se applicabile) la pagina Web di test.

    Se la pagina Web di origine o test viene servita da un'area geografica più vicina allo strumento che esegue il test delle prestazioni, potrebbe essere necessario usare uno strumento o richiedere un client in un'altra area per esaminare il vantaggio di prossimità del POP di Frontdoor di Azure.

    Importante

    Tutti i file serviti dall'esterno del nome host di Frontdoor di Azure non ne trarranno vantaggio. Potrebbe essere necessario riprogettare la pagina Web perché ciò accada.

    Se i file devono essere memorizzati nella cache, assicurarsi di testare i file con l'intestazione della risposta x-cache: TCP_HIT.

  6. Intervenire in base ai dati raccolti:

    • Se i dati raccolti indicano che i file vengono emessi da server esterni al nome host di Frontdoor di Azure, Frontdoor di Azure funziona come previsto.

      Il caricamento lento dei siti Web potrebbe richiedere una modifica nella progettazione della pagina Web. Per assistenza nell'ottimizzazione del sito Web per l'uso di Frontdoor di Azure, connettersi con il team di progettazione del sito Web o con i provider di soluzioni Microsoft.

      Nota

      Il problema del caricamento lento dei siti Web potrebbe richiedere tempo per la revisione, in base alla complessità della progettazione di un sito Web e alle relative istruzioni di chiamata file.

    • Se i dati raccolti indicano che le prestazioni di caricamento dei file sono migliori in Frontdoor di Azure rispetto al sito di origine o di test, Frontdoor di Azure funziona come previsto. L'origine del problema potrebbe essere costituita da singole richieste client. In tal caso, vedere Scenario 1 precedente in questo articolo.

    • Se i dati raccolti indicano che le prestazioni non sono migliori in Frontdoor di Azure, è probabile che sia necessario inviare una richiesta di supporto per ulteriori indagini. Includere un riferimento a questo articolo sulla risoluzione dei problemi e i passaggi eseguiti.