Partilhar via

Solucionar problemas gerais de desempenho com o Azure Front Door

  • Artigo

Os problemas de desempenho podem ter origem em várias áreas potenciais: o serviço Azure Front Door, a origem, o cliente solicitante ou o caminho entre qualquer um desses saltos. Este guia de solução de problemas ajuda você a identificar qual salto ao longo do caminho de dados é provavelmente a raiz de um problema e como resolvê-lo.

Verificar se há problemas conhecidos

Antes de começar, verifique se há problemas conhecidos em:

  • A plataforma Azure Front Door.
  • Fornecedores de serviços Internet (ISPs) no caminho.
  • A capacidade de o cliente requerente se ligar e obter dados.

Cenário 1: Investigar a origem

Se um dos servidores de origem estiver lento, o primeiro pedido de um objeto através do Azure Front Door será lento. Além disso, se o conteúdo não for colocado em cache no ponto de presença (POP) do Azure Front Door, os pedidos são reencaminhados para a origem. O serviço a partir da origem anula o benefício de proximidade do POP e da entrega local ao cliente requerente e, em vez disso, depende do desempenho da origem.

Cenário 1: Informações de ambiente necessárias

  • Nome do ponto de extremidade do Azure Front Door
    • Nome do anfitrião do ponto final
    • Domínio personalizado do ponto final (se aplicável)
    • Nome do anfitrião de origem
  • URL completo do ficheiro afetado

Cenário 1: Etapas de solução de problemas

  1. Verifique os cabeçalhos de resposta do pedido afetado.

    Para verificar os cabeçalhos de resposta, utilize os seguintes exemplos de curl no Bash. Também pode utilizar as ferramentas de programação do browser através da seleção da tecla F12. Selecione o separador Rede, selecione o ficheiro relevante a investigar e, em seguida, selecione o separador Cabeçalhos. Se o ficheiro não existir, volte a carregar a página com as ferramentas de programação abertas.

    A resposta inicial deve ter um x-cache cabeçalho com um TCP_MISS ou CONFIG_NOCACHE valor. O POP do Azure Front Door reencaminha os pedidos com este valor para a origem. A origem envia o tráfego de retorno nesse mesmo caminho para o cliente requerente.

    Segue-se um exemplo que 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

    Segue-se um exemplo que 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. Continue a efetuar o pedido ao ponto final até o cabeçalho x-cache ter um valor TCP_HIT.

    Se você viu CONFIG_NOCACHEinicialmente , o cache não está habilitado na configuração de rota. Neste caso, você não verá TCP_HIT.

  3. Se resolver o problema, a causa era a velocidade da origem e não o desempenho do Azure Front Door. O proprietário precisa de corrigir as definições de cache do Azure Front Door ou da origem para melhorar o desempenho.

    Se o problema persistir, a origem pode ser o cliente que está a pedir o conteúdo ou o serviço Azure Front Door. Aceda ao Cenário 2 para identificar a origem.

Cenário 2: Um único cliente ou local (por exemplo, um ISP) está lento

Pode existir lentidão num cliente único ou numa localização única se houver uma rota de rede incorreta entre o cliente requerente e o POP do Azure Front Door. Deve pôr de parte qualquer rota incorreta porque afeta a distância até ao POP, o que anula o benefício de proximidade do POP do Azure Front Door.

A latência alta ou a largura de banda baixa pode resultar de um problema de ISP, se estiver a utilizar uma rede privada virtual (VPN) ou fizer parte de uma rede empresarial dispersa. Uma rede empresarial pode executar todo o tráfego através de um ponto central remoto.

Cenário 2: Informações de ambiente necessárias

  • Nome do ponto de extremidade do Azure Front Door
    • Nome do anfitrião do ponto final
    • Domínio personalizado do ponto final (se aplicável)
    • Nome do anfitrião de origem
  • URL completo do ficheiro afetado
  • Solicitar informações do cliente
    • IP do cliente requerente
    • Localização do cliente requerente
    • O caminho do cliente requerente para o ambiente do Azure (geralmente identificado com tracert, pathping ou uma ferramenta semelhante)

Cenário 2: Etapas de solução de problemas

  1. Para verificar o caminho para o POP, utilize pathping ou uma ferramenta semelhante para 500 pacotes para verificar a rota de rede.

    O pathping tem um máximo de 250 consultas. Para testar até 500, execute a seguinte consulta duas vezes:

    pathping /q 250 <Full URL of Affected File>

  2. Determine se o tráfego está a seguir um caminho que adicione tempo ou aceda a uma região distante.

    Procure códigos de IP, cidade ou região que não sigam uma rota razoável com base na geografia (por exemplo, o tráfego na Europa está a ser encaminhado para os Estados Unidos) ou que tenham um número excessivo de saltos.

  3. Para pôr de parte as definições do cliente requerente, teste a partir de um cliente requerente diferente na mesma região.

  4. Se identificar saltos adicionais ou regiões remotas, o problema tem origem no cliente que acede ao POP do Azure Front Door e não no serviço Azure Front Door. O fornecedor de conectividade ou VPN tem de resolver os saltos entre pontos finais.

    Se não identificar saltos adicionais ou regiões remotas e o conteúdo estiver a ser servido a partir da cache (x-cache: TCP_HIT), o problema tem origem no serviço Azure Front Door. Talvez tenha de criar um pedido de suporte. Inclua uma referência a este artigo de resolução de problemas e aos passos que seguiu.

Nota

Quando o conteúdo está sendo veiculado desde a origem (x-cache: TCP_MISS), consulte o Cenário 1 anteriormente neste artigo.

Cenário 3: Um site carrega lentamente

Em determinados cenários, não há nenhum problema com um ficheiro único, mas o desempenho de uma página Web inteira (Azure Front Door com proxy) é insatisfatório. Uma ferramenta de desempenho de página Web mostra um mau desempenho do site em comparação com uma página Web não pertencente ao Azure Front Door.

Geralmente, uma página Web é composta por muitos ficheiros. Um site só beneficia do Azure Front Door se o Azure Front Door servir cada ficheiro numa página Web. Tem de configurar o Azure Front Door para maximizar o benefício.

Considere o seguinte exemplo:

  • Origem: origin.contoso.com
  • Domínio personalizado do Azure Front Door: contoso.com
  • Página que está a tentar carregar: https://contoso.com

Quando a página é carregada, o ficheiro inicial no diretório "/" chama outros ficheiros que criam a página. Estes ficheiros são imagens, JavaScript, ficheiros de texto e muitos outros. Se esses ficheiros não forem chamados pelo nome de anfitrião do Azure Front Door (contoso.com), a página não está a utilizar o Azure Front Door. Portanto, se um dos ficheiros pedidos pelo site for http://www.images.fabrikam.com/businessimage.jpg, o ficheiro não está a beneficiar da utilização do Azure Front Door. Em vez disso, o browser do cliente requerente está a pedir diretamente o ficheiro ao servidor images.fabrikam.com.

Diagrama de vários ficheiros com origens diferentes para um site singular e como essa configuração afeta o desempenho do Azure Front Door.

Cenário 3: Informações de ambiente necessárias

  • Nome do ponto de extremidade do Azure Front Door
    • Nome do anfitrião do ponto final
    • Domínio personalizado do ponto final (se aplicável)
    • Nome do anfitrião de origem
    • Localização geográfica da origem
  • URL completo da página Web afetada
  • Ferramenta e métrica que medem o desempenho

Cenário 3: Solução de problemas

  1. Reveja a métrica que mostra o desempenho mais lento.

    Importante

    A Microsoft não consegue discernir o que está sendo medido por ferramentas que não possui.

  2. Abra a página Web do Azure Front Door num browser e, em seguida abra as ferramentas de programação através da seleção da tecla F12.

    Pode utilizar as ferramentas de programação no browser para determinar a origem dos ficheiros que estão a ser servidos. Para ver o URL do pedido nas ferramentas de programação, selecione o separador Rede, selecione o ficheiro que está a investigar e, em seguida, selecione Geral. Se o ficheiro não existir, volte a carregar a página com as ferramentas de programação abertas.

  3. Observe a origem, ou o URL de pedido, dos ficheiros.

  4. Identifique os ficheiros que estão a utilizar ou não o nome de anfitrião do Azure Front Door.

    No exemplo anterior, uma imagem alojada no Azure Front Door seria https://www.contoso.com/productimage1.jpg. Uma imagem não alojada no Azure Front Door seria http://www.images.fabrikam.com/businessimage.jpg.

  5. Teste o desempenho do ficheiro servido pelo Azure Front Door, a respetiva origem e (se aplicável) a página Web de teste.

    Se a página Web de origem ou de teste for servida por uma região geográfica mais próxima da ferramenta que está a testar o desempenho, talvez tenha de utilizar uma ferramenta ou um cliente requerente noutra região para examinar o benefício de proximidade do POP do Azure Front Door.

    Importante

    Todos os arquivos servidos de fora do nome de host do Azure Front Door não se beneficiarão dele. Talvez tenha de redesenhar a página Web para esse fim.

    Se for suposto colocar em cache os ficheiros, certifique-se de que testa os ficheiros com o cabeçalho de resposta x-cache: TCP_HIT.

  6. Tome medidas com base nos dados recolhidos:

    • Se os dados recolhidos indicarem que os ficheiros estão a ser emitidos por servidores não pertencentes ao nome de anfitrião do Azure Front Door, este está a funcionar conforme esperado.

      O carregamento lento de sites pode exigir uma alteração no design da página Web. Para obter assistência para a otimização do seu site para utilizar o Azure Front Door, contacte a equipa de design do site ou os fornecedores de soluções da Microsoft.

      Nota

      O problema de carregar sites lentamente pode levar tempo para ser revisado, com base na complexidade do design de um site e suas instruções de chamada de arquivos.

    • Se os dados recolhidos indicarem que o desempenho de carregamento dos ficheiros é melhor no Azure Front Door em comparação com o site de origem ou teste, o Azure Front Door está a funcionar conforme esperado. A origem do problema pode ser os pedidos de clientes individuais. Nesse caso, consulte o Cenário 1 anteriormente neste artigo.

    • Se os dados recolhidos indicarem que o desempenho não é melhor no Azure Front Door, é provável que tenha de enviar um pedido de suporte para investigação adicional. Inclua uma referência a este artigo de resolução de problemas e aos passos que seguiu.