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

Сводка

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

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

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

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

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

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

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

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

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

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

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

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

    Пример ниже показывает 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 обслуживает, его источник и (если применимо) веб-страницу тестирования.

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

    Это важно

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

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

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

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

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

      Замечание

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

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

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

Связанный контент

  • Last updated on