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

Рекомендации по повышению производительности для 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. Войдите на портал Microsoft 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 предоставляет достаточные вычислительные ресурсы. Рекомендации по выбору соответствующей емкости см. в концепциях Microsoft Fabric .

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

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

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

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

Solution:

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

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

  • Last updated on