Поделиться через

Устранение общих проблем с производительностью с помощью Azure Front Door

  • Статья

Проблемы с производительностью могут возникнуть в нескольких потенциальных областях: служба Azure Front Door, источник, запрашивающий клиент или путь между любым из этих прыжков. Это руководство по устранению неполадок помогает определить, какой прыжок по пути данных, скорее всего, является корнем проблемы и как устранить проблему.

Проверка известных проблем

Прежде чем начать, проверьте наличие известных проблем:

  • Платформа Azure Front Door.
  • Поставщики услуг Интернета (ISP) в пути.
  • Способность запрашивающего клиента выполнять подключение и извлекать данные.

Сценарий 1. Исследование источника

Если один из серверов-источников работает медленно, первый запрос объекта через Azure Front Door также будет выполняться медленно. Кроме того, если содержимое не кэшируется в точке подключения Azure Front Door (POP), запросы пересылаются в источник. Обслуживание из источника не использует преимущества от близкого расположения POP и локальной доставки клиенту запроса, вместо этого такой подход зависит от производительности источника.

Сценарий 1. Необходимые сведения о среде

  • Имя конечной точки Azure Front Door
    • Имя узла конечной точки
    • Пользовательский домен конечной точки (если применимо)
    • Имя узла источника
  • Полный URL-адрес затрагиваемого файла

Сценарий 1. Устранение неполадок

  1. Проверьте заголовки ответов из затрагиваемого запроса.

    Чтобы проверить заголовки ответов, используйте следующие curl примеры в Bash. Вы также можете использовать средства для разработчиков в браузере, нажав клавишу F12. Перейдите на вкладку Сеть, выберите соответствующий файл, который нужно исследовать, после чего перейдите на вкладку Заголовки. Если файл отсутствует, перезагрузите страницу с открытыми средствами для разработчиков.

    Начальный x-cache ответ должен иметь заголовок с или CONFIG_NOCACHE значениемTCP_MISS. Служба POP Azure Front Door перенаправит запросы с этим значением на источник. Источник отправляет возвращаемый трафик на тот же путь запрашивающему клиенту.

    Пример ниже показывает 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

    Пример ниже показывает 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. Продолжайте запрашивать конечную точку до тех пор, пока заголовок x-cache не примет значение TCP_HIT.

    Если вы изначально видели CONFIG_NOCACHE, кэширование не включено в конфигурации маршрута. В этом случае вы не увидите TCP_HIT.

  3. Если проблема производительности устранена, то она была вызвана скоростью источника, а не производительностью Azure Front Door. Для повышения производительности владелец должен проверить параметры кэша Azure Front Door или источник.

    Если проблема не устранена, источником может выступать клиент, запрашивающий содержимое или службу Azure Front Door. Перейдите к сценарию 2 для выявления источника.

Сценарий 2. Медленно выполняется один клиент или расположение (например, поставщик услуг интернета вещей).

Один клиент или расположение может работать медленно, если между запрашивающим клиентом и Azure Front Door POP есть неправильный сетевой маршрут. Исключите ненадлежащие маршруты, поскольку они влияют на расстояние до POP, что нивелирует преимущество близкого расположения Azure Front Door POP.

Высокая задержка или низкая пропускная способность могут быть вызваны проблемами у поставщиков услуг Интернета, если вы используете виртуальную частную сеть (VPN), или участвуете в распределенной корпоративной сети. Корпоративная сеть может проводить весь трафик через централизованную удаленную точку.

Сценарий 2. Необходимые сведения о среде

  • Имя конечной точки Azure Front Door
    • Имя узла конечной точки
    • Пользовательский домен конечной точки (если применимо)
    • Имя узла источника
  • Полный URL-адрес затрагиваемого файла
  • Запрос сведений о клиенте
    • Запрос IP-адреса клиента
    • Запрос расположения клиента
    • Запрос пути клиента к среде Azure (обычно идентифицируется с помощью tracert, pathping или аналогичного инструмента)

Сценарий 2. Действия по устранению неполадок

  1. Чтобы проверить путь к POP, используйте pathping или аналогичный инструмент для 500 пакетов, позволяющий проверить сетевой маршрут.

    Pathping может иметь максимум 250 запросов. Для тестирования до 500 запросов выполните следующий запрос дважды:

    pathping /q 250 <Full URL of Affected File>

  2. Определите, проходит ли трафик по маршруту, который увеличивает время или дистанцию прохождения до удаленного региона.

    Обращайте внимание на IP-адреса, города или коды регионов, которые не относятся к разумному маршруту для вашего географического региона (например, трафик в Европе направляется в Соединенные Штаты) или на слишком большое количество переходов.

  3. Чтобы исключить запросы параметров клиента, проверьте другой запрашивающий клиент в том же регионе.

  4. Если будут выявлены дополнительные переходы или удаленные регионы, значит проблема вызвана обращением клиента к Azure Front Door POP, а не самой службой Azure Front Door. Поставщик подключений или VPN должен решить проблему слишком большого числа переходов между конечными точками.

    Если лишние переходы или удаленные регионы не выявлены, при этом содержимое обслуживается из кэша (x-cache: TCP_HIT), проблема связана со службой Azure Front Door. Возможно, потребуется создать запрос на поддержку. Включите ссылку на эту статью по устранению неполадок и предпринятые действия.

Примечание.

Когда содержимое обслуживается из источника (x-cache: TCP_MISS), см . сценарий 1 ранее в этой статье.

Сценарий 3. Веб-сайт загружается медленно

В некоторых сценариях могут отсутствовать проблемы с загрузкой единичных файлов, при этом производительность всей веб-страницы (прокси-страница Azure Front Door) будет неудовлетворительной. Средство контроля производительности веб-страницы показывает низкую производительность сайта по сравнению с веб-страницами за пределами Azure Front Door.

Веб-страница часто состоит из множества файлов. Веб-сайт получает преимущества от использования Azure Front Door только в том случае, если Azure Front Door обслуживает каждый файл на веб-странице. Для получения максимальных преимуществ необходимо настроить Azure Front Door.

Рассмотрим следующий пример:

  • Источник: origin.contoso.com
  • Пользовательский домен Azure Front Door: contoso.com
  • Страница, которую вы пытаетесь загрузить: https://contoso.com

При загрузке страницы исходный файл в каталоге "/" вызывает другие файлы для создания страницы. Эти файлы с изображениями, JavaScript, текстовые файлы и многие другие. Если не удается вызвать эти файлы с помощью имени узла Azure Front Door (contoso.com), страница не использует Azure Front Door. Таким образом, если один из запрашиваемых веб-сайтом файлов http://www.images.fabrikam.com/businessimage.jpg, файл не получает преимуществ от использования Azure Front Door. Вместо этого браузер на запрашивающем клиенте запрашивает файл непосредственно с сервера images.fabrikam.com.

Схема нескольких файлов из разных источников для одного веб-сайта и влияние такой конфигурации на производительность Azure Front Door.

Сценарий 3. Необходимые сведения о среде

  • Имя конечной точки Azure Front Door
    • Имя узла конечной точки
    • Пользовательский домен конечной точки (если применимо)
    • Имя узла источника
    • Географическое расположение источника
  • Полный URL-адрес затрагиваемой веб-страницы
  • Инструмент и метрика для измерения производительности

Сценарий 3. Устранение неполадок

  1. Изучите метрику, демонстрирующую более низкую производительность.

    Внимание

    Корпорация Майкрософт не может определить, что измеряется инструментами, которыми он не владеет.

  2. Откройте веб-страницу Azure Front Door в браузере, а затем откройте средства для разработчиков, нажав клавишу F12.

    Средства для разработчиков в браузере можно использовать для определения источника обслуживаемых файлов. Чтобы просмотреть URL-адрес запроса в средствах для разработчика, перейдите на вкладку Сеть, выберите анализируемый файл, после чего выберите Общие. Если файл отсутствует, перезагрузите страницу с открытыми средствами для разработчиков.

  3. Обратите внимание на источник или URL-адрес запроса файлов.

  4. Определите, какие файлы используют имя узла Azure Front Door и какие нет.

    В предыдущем примере образ, размещенный в Azure Front Door — это https://www.contoso.com/productimage1.jpg. Образ, который не размещен в Azure Front Door — это http://www.images.fabrikam.com/businessimage.jpg.

  5. Проверьте производительность файла, обслуживаемого Azure Front Door, его источник и (если применимо) веб-страницу тестирования.

    Если веб-страница источника или тестирования обслуживается из географического региона ближе к инструменту, который тестирует производительность, может потребоваться использование инструмента или запрашивающего клиента в другом регионе для изучения преимуществ близкого расположения POP Azure Front Door.

    Внимание

    Все файлы, обслуживаемые за пределами имени узла Azure Front Door, не будут использовать его. Для этого может потребоваться изменение веб-страницы.

    Если файлы должны кэшироваться, обязательно протестируйте файлы с заголовком ответа x-cache: TCP_HIT.

  6. Выполните действия на основе собранных данных:

    • Если собранные данные показывают, что файлы выдаются с серверов за пределами имени узла Azure Front Door, Azure Front Door работает нормально.

      В случае медленной загрузки веб-сайтов может потребоваться изменение дизайна веб-страницы. Для получения поддержки с оптимизацией веб-сайта для использования Azure Front Door свяжитесь с командой разработчиков веб-сайтов или с поставщиками решений Майкрософт.

      Примечание.

      Проблема медленной загрузки веб-сайтов может занять некоторое время, основываясь на сложности дизайна веб-сайта и его инструкций по вызову файлов.

    • Если собранные данные показывают, что производительность загрузки файлов через Azure Front Door выше по сравнению с загрузкой из источника или с тестового сайта, Azure Front Door работает нормально. Причиной проблемы могут быть отдельные клиентские запросы. В этом случае см . сценарий 1 выше в этой статье.

    • Если собранные данные показывают, что производительность в Azure Front Door не улучшается, скорее всего, потребуется отправить запрос на поддержку для дальнейшего изучения. Включите ссылку на эту статью по устранению неполадок и предпринятые действия.