Рекомендации по повышению производительности для API Fabric в GraphQL

API Microsoft Fabric для GraphQL предлагает эффективный способ эффективного запроса данных, но оптимизация производительности является ключом к обеспечению плавной и масштабируемой производительности. Независимо от того, обрабатываете ли вы сложные запросы или оптимизируете время отклика, приведенные ниже рекомендации помогут повысить производительность реализации GraphQL и повысить эффективность API в Fabric.

Кто нуждается в оптимизации производительности

Оптимизация производительности имеет решающее значение для:

  • Разработчики приложений, разрабатывающие высоконагруженные приложения, которые обращаются к lakehouses и хранилищам данных Fabric
  • Инженеры данных оптимизируют шаблоны доступа к данным Fabric для крупномасштабных аналитических приложений и процессов ETL
  • Администраторы рабочей области Fabric управляют потреблением ресурсов и обеспечивают их эффективное использование
  • Разработчики бизнес-аналитики улучшают время отклика для пользовательских приложений аналитики, созданных на основе данных Fabric
  • Команды DevOps , устраняющие проблемы с задержкой в рабочих приложениях, использующих API Fabric

Используйте эти рекомендации, если API GraphQL должен эффективно обрабатывать рабочие нагрузки или при возникновении проблем с производительностью.

Выравнивание региона

Вызовы API между регионами являются распространенной причиной высокой задержки. Для оптимальной производительности убедитесь, что клиентские приложения, клиент Fabric, емкость и источники данных находятся в одном регионе Azure.

Проверьте регион клиента

Чтобы найти регион клиента Fabric, выполните приведенные ниже действия.

  1. Войдите в портал Fabric с учётной записью администратора
  2. Щелкните значок справки (?) в правом верхнем углу
  3. В нижней части области справки выберите О Fabric
  4. Обратите внимание на регион, отображаемый в сведениях о клиенте.

Проверьте регион емкости

Ваш API для GraphQL выполняется в пределах определенной производительности. Чтобы найти регион емкости, выполните следующие действия.

  1. Откройте рабочую область, в которой размещен API для GraphQL.

  2. Перейти к параметрам рабочей области>Тип рабочей области

  3. Найдите регион по лицензионной емкости

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

Проверка региона источника данных

Расположение источников данных также влияет на производительность:

  • Источники данных Fabric (Lakehouse, хранилище данных, база данных SQL): они используют тот же регион, что и емкость рабочей области.
  • Внешние источники данных (база данных SQL Azure и т. д.): проверьте расположение ресурса на портале Azure.

Рекомендация. Развертывание клиентских приложений в том же регионе, что и емкость и источники данных Fabric, чтобы свести к минимуму задержку в сети.

Рекомендации по тестированию производительности

При оценке производительности API следуйте этим рекомендациям для надежных и согласованных результатов.

Использование реалистичных средств тестирования

Проверьте с помощью инструментов, которые тесно соответствуют рабочей среде:

  • Скрипты или приложения: используйте скрипты Python, Node.jsили .NET, имитирующие фактическое поведение клиента.
  • Пул http-подключений: повторное использование HTTP-подключений для уменьшения задержки, особенно важной для сценариев между регионами
  • Управление сеансами: поддержание сеансов между запросами для точного отражения использования в реальных условиях

Примеры ресурсов:

Сбор значимых метрик

Для точной оценки производительности:

  1. Автоматизация тестирования. Использование скриптов или средств тестирования производительности для последовательного выполнения тестов в течение определенного периода
  2. Разогрейте API: выполните несколько тестовых запросов перед измерением производительности (см. сведения о требованиях к прогревам)
  3. Анализ распределения: используйте метрики на основе процентиля (P50, P95, P99), а не просто средние значения для понимания шаблонов задержки
  4. Тестирование под нагрузкой: Измерение производительности при реалистичных объемах параллельных запросов
  5. Условия документа: запишите время дня, использование емкости и любые параллельные рабочие нагрузки во время тестирования

Распространенные проблемы с производительностью

Общие сведения об этих распространенных проблемах помогают эффективно диагностировать и устранять проблемы с производительностью.

Требования к прогревам

Проблема. Первый запрос API занимает значительно больше времени, чем последующие запросы.

Почему это происходит:

  • Инициализация API: при простое среда API должна инициализироваться во время первого вызова, добавив несколько секунд задержки.
  • Прогрев источников данных: многие источники данных (особенно SQL Analytics и хранилища данных) проходят стадию прогрева после простоя.
  • Объединенная инициализация: если API и источник данных неактивны, время инициализации суммируется.

Solution:

  • Выполнение 2-3 тестовых запросов перед измерением производительности
  • Для производственных приложений реализуйте конечные точки проверки работоспособности, которые поддерживают API в активном состоянии.
  • Рекомендуется использовать запланированные запросы или средства мониторинга для поддержания активного состояния в рабочее время

Региональное несоответствие

Проблема: постоянно высокая задержка во всех запросах.

Почему это происходит: Сетевые вызовы между регионами добавляют значительную задержку, особенно если клиент, API и источники данных находятся в разных регионах Azure.

Solution:

  • Убедитесь, что клиентское приложение, емкость Fabric и источники данных находятся в одном регионе
  • Если доступ между регионами неизбежен, реализуйте агрессивные стратегии кэширования
  • Рассмотрите возможность развертывания региональных реплик API для глобальных приложений

Производительность источника данных

Проблема: Запросы API медленные, даже когда API разогреты и регионы выровнены.

Почему это происходит: API для GraphQL выступает в качестве интерфейса запроса по источникам данных. Если базовый источник данных имеет проблемы с производительностью, такие как отсутствующие индексы, сложные запросы или ограничения ресурсов, API наследует эти ограничения.

Solution:

  1. Тестирование напрямую. Запрос источника данных напрямую (с помощью SQL или других собственных средств) для установления базовой производительности
  2. Оптимизация источника данных:
  3. Оптимальная емкость: проверьте, что емкость SKU для Fabric предоставляет достаточные вычислительные ресурсы. См. Fabric concepts для рекомендаций по выбору соответствующей вместимости.

Конструктор запросов

Проблема. Некоторые запросы выполняются хорошо, а другие медленно.

Почему это происходит:

  • Чрезмерное получение: запрос большего количества полей, чем это необходимо, увеличивает время обработки
  • Глубокое вложение: Запросы с множеством уровней вложенных отношений требуют нескольких выполнений резолвера.
  • Отсутствующие фильтры: запросы без соответствующих фильтров могут возвращать чрезмерные данные

Solution:

  • Запрос только полей, необходимых в запросе GraphQL
  • Ограничение глубины вложенных связей по возможности
  • Использование соответствующих фильтров и разбиения на страницы в запросах
  • При необходимости рассмотрите возможность разбиения сложных запросов в несколько простых запросов.

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

  • Last updated on