Compartir a través de

Solución de problemas generales de rendimiento con Azure Front Door

  • Artículo

Los problemas de rendimiento pueden originarse en varias áreas posibles: el servicio de Azure Front Door, el origen, el cliente solicitante o la ruta de acceso entre cualquiera de estos saltos. Esta guía de solución de problemas ayuda a identificar qué salto en la ruta de datos es más probable que sea la raíz del problema y cómo resolverlo.

Comprobación de problemas conocidos

Antes de empezar, compruebe si hay problemas conocidos en:

  • La plataforma de Azure Front Door.
  • Proveedores de servicios de Internet (ISP por sus siglas en inglés) en el camino.
  • La capacidad del cliente solicitante para conectarse y recuperar datos.

Escenario 1: Investigar el origen

Si uno de los servidores de origen está lento, la primera solicitud de un objeto a través de Azure Front Door será lenta. Además, si el contenido no se almacena en caché en el punto de presencia (POP por sus siglas en inglés) de la puerta de enlace de Azure, las solicitudes se reenvían al origen. Servir desde el origen niega la ventaja de la proximidad del POP y la entrega local al cliente solicitante, y, en su lugar, depende del rendimiento del origen.

Escenario 1: Información del entorno necesaria

  • Nombre del punto de conexión de Azure Front Door
    • Nombre del host del punto final
    • Dominio personalizado del punto final (si corresponde)
    • Nombre de host de origen
  • URL completa del archivo afectado

Escenario 1: Pasos de solución de problemas

  1. Compruebe los encabezados de respuesta de la solicitud afectada.

    Para verificar los encabezados de respuesta, use los siguientes curl ejemplos en Bash. También puede utilizar las herramientas de desarrollo de su navegador seleccionando la tecla F12. Seleccione la pestaña de Trabajo en Red, seleccione el archivo relevante que se investigará y, a continuación, seleccione la pestaña de Encabezados Si falta el archivo, vuelva a cargar la página con las herramientas del desarrollador abiertas.

    La respuesta inicial debe tener un encabezado x-cache con un valor de TCP_MISS o CONFIG_NOCACHE. El POP de la puerta de entrada de Azure reenvía las solicitudes con este valor al origen. El origen envía el tráfico de retorno en esa misma ruta al cliente solicitante.

    Aquí hay un ejemplo que muestra 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

    Aquí hay un ejemplo que muestra 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. Continúe solicitando el punto final hasta que x-cache el encabezado tenga un TCP_HIT valor.

    Si inicialmente vio CONFIG_NOCACHE, el almacenamiento en caché no está habilitado en la configuración de ruta. En este caso, no verá TCP_HIT.

  3. Si se resuelve el problema de rendimiento, el problema se basó en la velocidad del origen y no en el rendimiento de la Puerta de Entrada de Azure. El propietario debe abordar la configuración del caché de la puerta de entrada de Azure o el origen para mejorar el rendimiento.

    Si el problema persiste, el origen podría ser el cliente que solicita el contenido o el servicio de laPuerta de Entrada de Azure. Pase al escenario 2 para identificar el origen.

Escenario 2: Un solo cliente o ubicación (ejemplo, un ISP) es lento

Un único cliente o ubicación puede ser lento si hay una ruta de red incorrecta entre el cliente solicitante y el POP de Azure Front Door. Debe descartar cualquier ruta incorrecta porque afecta la distancia al POP, lo que elimina el beneficio de proximidad del POP de la Puerta de entrada de Azure.

La alta latencia o el bajo ancho de banda podrían ser el resultado de un problema de ISP, si está utilizando una red privada virtual (VPN por sus siglas en inglés) o forma parte de una red corporativa dispersa. Una red corporativa puede ejecutar todo el tráfico a través de un punto remoto central.

Escenario 2: Información del entorno necesaria

  • Nombre del punto de conexión de Azure Front Door
    • Nombre del host del punto final
    • Dominio personalizado del punto final (si corresponde)
    • Nombre de host de origen
  • URL completa del archivo afectado
  • Solicitud de información de cliente
    • IP del cliente solicitante
    • Solicitud de ubicación del cliente
    • Solicitud de la ruta de acceso de cliente al entorno de Azure (normalmente identificada con tracert, pathping o una herramienta similar)

Escenario 2: Pasos de solución de problemas

  1. Para comprobar la ruta de acceso al POP, use pathping o una herramienta similar para 500 paquetes para comprobar la ruta de red.

    Pathping tiene un máximo de 250 consultas. Para probar a 500, ejecute la siguiente consulta dos veces:

    pathping /q 250 <Full URL of Affected File>

  2. Determine si el tráfico está tomando una ruta que agregaría tiempo o viajaría a una región distante.

    Busque los códigos de IP, ciudad o región que no tomen una ruta razonable según su geografía (por ejemplo, el tráfico en Europa se dirige a los Estados Unidos) o que tengan una cantidad excesiva de saltos.

  3. Para descartar la configuración del cliente solicitante, pruebe desde un cliente solicitante diferente en la misma región.

  4. Si identifica los saltos adicionales o regiones remotas, el problema radica en que el cliente accede al POP de la Puerta Delantera de Azure y no en el servicio de la Puerta Frontal de Azure en sí. El proveedor de conectividad o VPN debe abordar los saltos entre los puntos finales.

    Si no identifica los saltos adicionales o regiones remotas y el contenido se presenta desde el caché (x-cache: TCP_HIT), el problema es con el servicio de la puerta de entrada de Azure. Es posible que deba crear una solicitud de soporte. Incluya una referencia a este artículo de solución de problemas y los pasos que tomó.

Nota:

Cuando el contenido se sirve desde el origen (x-cache: TCP_MISS), consulte Escenario 1 más atrás en este artículo.

Escenario 3: Un sitio web se carga lentamente

En algunos escenarios, no hay ningún problema con un único archivo, pero el rendimiento de una página web completa (proxy de Azure Front Door) no es satisfactorio. Una herramienta de rendimiento de la página web muestra un rendimiento deficiente del sitio en comparación con una página web fuera de la puerta de entrada de Azure.

Una página web suele constar de muchos archivos. Un sitio web se beneficia de la Puerta de Entrada de Azure solo si la Puerta de Entrada de Azure presenta cada archivo de la página web. Debe configurar la Puerta de Entrada de Azure para maximizar el beneficio.

Considere el ejemplo siguiente:

  • Origen: origin.contoso.com
  • Dominio personalizado de la Puerta de Entrada de Azure: contoso.com
  • La página que está intentando cargar: https://contoso.com

Cuando se carga la página, el archivo inicial en el directorio "/" llama a otros archivos, que construyen la página. Estos archivos son imágenes, JavaScript, archivos de texto y más. Si no se llama a esos archivos a través del nombre del host de la Puerta de Entrada de Azure (contoso.com), la página no utiliza la Puerta de Entrada de Azure. Entonces, si uno de los archivos que solicita el sitio web es http://www.images.fabrikam.com/businessimage.jpg, el archivo no se beneficia del uso de la Puerta de Entrada de Azure. En su lugar, el navegador del cliente solicitante solicita el archivo directamente al images.fabrikam.com servidor.

Diagrama de varios archivos de origen diferente para un sitio web único y cómo esa configuración afecta al rendimiento de Azure Front Door.

Escenario 3: Información del entorno necesaria

  • Nombre del punto de conexión de Azure Front Door
    • Nombre del host del punto final
    • Dominio personalizado del punto final (si corresponde)
    • Nombre de host de origen
    • Ubicación geográfica del origen
  • URL completa de la página web afectada
  • Herramienta y métrica que miden el rendimiento

Escenario 3: Solución de problemas

  1. Revise la métrica que muestra el rendimiento más lento.

    Importante

    Microsoft no puede distinguir lo que se mide mediante herramientas que no posee.

  2. Abra la página web de Azure Front Door en un explorador y, a continuación, abra las herramientas de desarrollo seleccionando la tecla F12.

    Puede utilizar las herramientas de desarrollador de su navegador para determinar el origen de los archivos que se entregan. Para ver la URL de la SOLICITUD en las herramientas para desarrolladores, seleccione la pestaña del Trabajo en Red, seleccione el archivo que está investigando y, a continuación, seleccione Generalidades. Si falta el archivo, vuelva a cargar la página con las herramientas del desarrollador abiertas.

  3. Anote el origen o la URL de solicitud de los archivos.

  4. Identifique qué archivos usan el nombre del host de la Puerta de Entrada de Azure y cuáles no.

    En el ejemplo anterior, una imagen alojada en la Puerta de Entrada de Azure sería https://www.contoso.com/productimage1.jpg. Una imagen no alojada en la Puerta de Entrada de Azure sería http://www.images.fabrikam.com/businessimage.jpg.

  5. Pruebe el rendimiento del archivo que la Puerta de Entrada de Azure está entregando, su origen y (si corresponde) la página web de prueba.

    Si la página web de origen o de prueba se entrega desde una región geográfica más cercana a la herramienta que está probando el rendimiento, es posible que deba usar una herramienta o un cliente solicitante en otra región para examinar el beneficio de proximidad del POP de la puerta de entrada de Azure.

    Importante

    Los archivos servidos desde fuera del nombre de host de Azure Front Door no se beneficiarán de él. Es posible que tenga que rediseñar la página web para hacerlo.

    Si los archivos están destinados a ser almacenados en el caché, asegúrese de probar los archivos que tienen el encabezado de respuesta x-cache: TCP_HIT.

  6. Tome medidas en función de los datos recopilados:

    • Si los datos recopilados muestran que los archivos se emiten desde los servidores fuera del nombre del host de la Puerta de Entrada de Azure, la Puerta de Entrada de Azure funciona como se esperaba.

      La carga lenta de los sitios web puede requerir de un cambio en el diseño de la página web. Para obtener ayuda para optimizar su sitio web para usar la Puerta de Entrada de Azure, conéctese con su equipo de diseño de sitios web o con los Proveedores de soluciones de Microsoft.

      Nota:

      El problema de carga lenta de sitios web podría tardar un tiempo en revisarse en función de la complejidad del diseño del sitio web y de las instrucciones de llamada a archivos.

    • Si los datos recopilados muestran que el rendimiento de carga de los archivos es mejor en Azure Front Door en comparación con el origen o el sitio de prueba, Azure Front Door funciona según lo previsto. El origen del problema podría ser las solicitudes de clientes individuales. En ese caso, consulte Escenario 1 más atrás en este artículo.

    • Si los datos recopilados muestran que el rendimiento es no mejor en la Puerta de Entrada de Azure, es probable que deba presentar una solicitud de soporte para una investigación adicional. Incluya una referencia a este artículo de solución de problemas y los pasos que tomó.