Partager via

Bonnes pratiques relatives aux performances de l’API Fabric pour GraphQL

L’API Microsoft Fabric pour GraphQL offre un moyen puissant d’interroger efficacement les données, mais l’optimisation des performances est essentielle pour garantir des performances fluides et évolutives. Que vous gériez des requêtes complexes ou optimisez les temps de réponse, les bonnes pratiques suivantes vous aident à tirer le meilleur parti de votre implémentation GraphQL et à optimiser l’efficacité de votre API dans Fabric.

Régions

Les appels interrégions peuvent généralement être la cause d’une latence élevée. Pour obtenir les meilleures performances, il est recommandé d’avoir des clients qui se connectent aux API dans la même région de locataire et de capacité.

Région du locataire

Vous trouverez votre région de locataire en procédant comme suit :

  1. Accédez au portail Microsoft Fabric avec un compte d’administrateur, puis cliquez sur l’icône Aide ? dans le coin supérieur droit.
  2. En bas de la section Aide, cliquez sur le lien À propos de Fabric.
  3. Les détails de votre locataire, y compris la région, sont affichés.

Région de capacité

  1. Accédez au portail Microsoft Fabric, ouvrez l’espace de travail qui héberge l’API de votre infrastructure pour GraphQL.

  2. Dans les paramètres de l’espace de travail, accédez aux informations de licence.

  3. Vous trouverez les informations de votre région de capacité sous capacité de licence.

    Capture d’écran montrant comment obtenir la région de capacité de votre espace de travail.

Région de source de données

  1. Si votre source de données est hébergée dans la plateforme Fabric, la région de capacité de l’espace de travail est la région de source de données.

  2. Si votre source de données se trouve en dehors de la plateforme Fabric, par exemple une base de données Azure SQL, vous devez être en mesure de trouver les informations régionales dans le portail Azure.

Tests de performances

Pour les clients qui évaluent leurs performances d’API, nous vous recommandons de respecter les instructions suivantes pour garantir des résultats cohérents et fiables.

Outils côté client

Pour émuler le comportement de votre application, il est recommandé d’utiliser des scripts ou une application web de démonstration pour effectuer des tests de performance. En plus de cela, l’utilisation du regroupement de connexions HTTP peut réduire considérablement les latences en particulier pour les scénarios interrégions.

Vous pouvez utiliser cet exemple de script de test de performances qui peut vous aider à commencer.

Articles associés :

Collecte et évaluation des données

Il est conseillé d’automatiser l’exécution de la requête sur une période bien définie à l’aide de scripts ou d’outils de test de performances. L’analyse des résultats moyens ou centiles permet de garantir des mesures de performances plus précises et non biaisées.

Problèmes courants

Voici la liste des problèmes courants qui peuvent avoir un impact sur la latence et les performances de l’API.

  • Votre emplacement géographique client est différent de votre locataire et de votre région de capacité :

    • Si vous envisagez d’obtenir les meilleures performances pour votre application, le fait d’avoir des clients et des ressources d’API dans la même région permet d’atteindre l’objectif.

  • Interrogez l’API pour GraphQL quelques fois avant de tester :

    • L’API pour GraphQL n’utilise pas ou ne consomme pas de capacité lorsqu’elle est inactive. Cela signifie que l’environnement d’API doit être initialisé en interne pendant le premier appel, ce qui prend quelques secondes supplémentaires. L’API pour GraphQL dispose de mécanismes de mise en cache internes pour réduire les latences pour les appels continus, mais vous pouvez rencontrer des pics de latence pour les appels initiaux.
    • À part l’API elle-même, certaines sources de données sont connues pour subir une phase de préchauffement, ce qui entraîne des latences plus élevées pour les requêtes initiales. Si l’API accède également à une source de données inactive et doit également être initialisée lors de la première exécution, la latence est plus élevée, car elle doit attendre l’initialisation de la source de données et de l’API.
    • Les appels suivants sont plus rapides, car l’initialisation de l’environnement ne se produit qu’une seule fois.

  • Configuration liée à la source de données et à la capacité du réseau.

    • Vous pouvez considérer l’API pour GraphQL comme wrapper au-dessus de vos sources de données. Si votre source de données elle-même présente des problèmes de performances en raison de la nature de sa complexité, il est prévu que les latences d’API peuvent être élevées. Lorsque de tels cas se produisent, il est recommandé de tester l’interrogation de vos sources de données directement pour une comparaison de performances plus efficace avec celle de l’API pour GraphQL.

    • Lors de l’accès à l’API pour GraphQL, les performances vont être liées par la référence SKU de capacité Fabric que vous avez sélectionnée.

Plusieurs facteurs peuvent avoir un impact sur les performances de l’API. Comprendre la configuration de votre source de données, sélectionner les régions appropriées et mesurer efficacement les performances est cruciale pour l’optimisation.

Contenu connexe

  • Last updated on