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.

Qui a besoin d’une optimisation des performances

L’optimisation des performances est essentielle pour :

• Développeurs d’applications qui créent des applications à trafic élevé interrogeant des data lakehouses et des entrepôts de Fabric
• Ingénieurs données optimisant les modèles d’accès aux données Fabric pour les applications d’analytique à grande échelle et les processus ETL
• Administrateurs de l’espace de travail Fabric gérant la consommation de capacité et garantissant une utilisation efficace des ressources
• Développeurs décisionnels améliorant les temps de réponse pour les applications d’analytique personnalisée basées sur des données Fabric
• Les équipes DevOps résolvent les problèmes de latence dans les applications de production consommant des API Fabric

Utilisez ces meilleures pratiques lorsque votre API GraphQL doit gérer efficacement les charges de travail de production ou lorsque vous rencontrez des problèmes de performances.

Alignement de la région

Les appels d’API inter-régions sont une cause courante de latence élevée. Pour des performances optimales, assurez-vous que vos applications clientes, votre locataire Fabric, votre capacité et vos sources de données se trouvent dans la même région Azure.

Vérifier votre région de locataire

Pour trouver la région de votre locataire Fabric :

1. Connectez-vous au portail Microsoft Fabric avec un compte d’administrateur
2. Sélectionnez l’icône d’aide ( ?) dans le coin supérieur droit
3. En bas du volet d’aide, sélectionnez À propos de Fabric
4. Notez la région affichée dans les détails du locataire

Vérifier votre région de capacité

Votre API pour GraphQL s’exécute dans une capacité spécifique. Pour trouver la région de capacité :

1. Ouvrir l’espace de travail hébergeant votre API pour GraphQL

2. Accéder aux paramètres de l’espace de travail>informations de licence

3. Rechercher la région sous capacité de licence

   

Vérifier votre région de source de données

L’emplacement de vos sources de données a également un impact sur les performances :

• Sources de données Fabric (Lakehouse, Data Warehouse, SQL Database) : elles utilisent la même région que la capacité de l’espace de travail
• Sources de données externes (Azure SQL Database, etc.) : vérifiez l’emplacement des ressources dans le portail Azure

Bonne pratique : déployez des applications clientes dans la même région que vos sources de données et capacité Fabric pour réduire la latence réseau.

Meilleures pratiques de test des performances

Lors de l’évaluation des performances de votre API, suivez ces instructions pour obtenir des résultats fiables et cohérents.

Utiliser des outils de test réalistes

Testez avec des outils qui correspondent étroitement à votre environnement de production :

• Scripts ou applications : utiliser Python, Node.jsou des scripts .NET qui simulent le comportement réel du client
• Regroupement de connexions HTTP : réutiliser les connexions HTTP pour réduire la latence, en particulier pour les scénarios interrégions
• Gestion des sessions : Gérer les sessions entre les demandes pour refléter avec précision l’utilisation réelle

Exemples de ressources :

• Exemple de script de test de performances (notebook Python)
• Objets de session HTTP dans Python
• Instructions HttpClient pour .NET

Collecter des métriques significatives

Pour une évaluation précise des performances :

1. Automatiser les tests : utiliser des scripts ou des outils de test de performances pour exécuter des tests de manière cohérente sur une période définie
2. Préchauffez l’API : exécutez plusieurs requêtes de test avant de mesurer les performances (consultez les exigences de préchauffage)
3. Analyser les distributions : utilisez des métriques basées sur centile (P50, P95, P99) plutôt que simplement des moyennes pour comprendre les modèles de latence
4. Test sous charge : mesurer les performances avec des volumes de requêtes simultanés réalistes
5. Conditions du document : enregistrer l’heure du jour, l’utilisation de la capacité et toutes les charges de travail simultanées pendant le test

Problèmes de performances courants

La compréhension de ces problèmes courants vous permet de diagnostiquer et de résoudre efficacement les problèmes de performances.

Exigences de préchauffement

Problème : la première requête d’API prend beaucoup plus de temps que les requêtes suivantes.

Pourquoi cela se produit :

• Initialisation de l’API : en cas d’inactivité, l’environnement d’API doit s’initialiser pendant le premier appel, en ajoutant quelques secondes de latence
• Préchauffement de la source de données : de nombreuses sources de données (en particulier les points de terminaison SQL Analytics et les entrepôts de données) subissent une phase de préchauffement lorsqu’elles sont sollicitées après avoir été inactives
• Initialisation combinée : si l’API et la source de données sont inactives, les temps d’initialisation sont composés

Solution:

• Exécuter 2 à 3 requêtes de test avant de mesurer les performances
• Pour les applications de production, implémentez des points de terminaison de contrôle d’intégrité qui conservent la chaleur de l’API
• Envisagez d’utiliser des requêtes planifiées ou des outils de surveillance pour maintenir un état actif pendant les heures d’ouverture

Mauvais alignement régional

Problème : latence élevée cohérente entre toutes les requêtes.

Pourquoi cela se produit : Les appels réseau interrégions ajoutent une latence importante, en particulier lorsque le client, l’API et les sources de données se trouvent dans différentes régions Azure.

Solution:

• Vérifiez que votre application cliente, votre capacité Fabric et vos sources de données se trouvent dans la même région.
• Si l’accès interrégion est inévitable, implémentez des stratégies de mise en cache agressives
• Envisagez de déployer des réplicas d’API régionaux pour les applications globales

Performances de la source de données

Problème : les demandes d’API sont lentes même lorsque l’API est réchauffée et que les régions sont alignées.

Pourquoi cela se produit : L’API pour GraphQL agit comme une interface de requête sur vos sources de données. Si la source de données sous-jacente présente des problèmes de performances( tels que des index manquants, des requêtes complexes ou des contraintes de ressources), l’API hérite de ces limitations.

Solution:

1. Tester directement : interroger la source de données directement (à l’aide de SQL ou d’autres outils natifs) pour établir des performances de base de référence
2. Optimisez la source de données :
   • Ajouter des index appropriés pour les colonnes fréquemment interrogées
   • Considérez le magasin de données approprié pour votre cas d’usage : guide de décision Fabric : choisir un magasin de données
   • Passer en revue les plans d’exécution des requêtes pour les opportunités d’optimisation
3. Capacité de taille appropriée : assurez-vous que votre référence SKU de capacité Fabric fournit des ressources de calcul suffisantes. Consultez les concepts de Microsoft Fabric pour obtenir des conseils sur la sélection de la capacité appropriée.

Conception de requête

Problème : certaines requêtes fonctionnent correctement, tandis que d’autres sont lentes.

Pourquoi cela se produit :

• Over-fetching : Solliciter plus de champs que nécessaire augmente le temps de traitement
• Imbrication profonde : les requêtes avec de nombreux niveaux de relations imbriquées nécessitent plusieurs exécutions de résolveurs
• Filtres manquants : les requêtes sans filtres appropriés peuvent retourner des données excessives

Solution:

• Demander uniquement les champs dont vous avez besoin dans votre requête GraphQL
• Limiter la profondeur des relations imbriquées si possible
• Utiliser les filtres et la pagination appropriés dans vos requêtes
• Envisagez de diviser des requêtes complexes en plusieurs requêtes plus simples si nécessaire

Contenu connexe

• Vue d’ensemble de l’API Fabric pour GraphQL
• Éditeur d’API Fabric pour GraphQL