Teilen über


Bewährte Methoden für die Leistung der Fabric-API für GraphQL

Die API von Microsoft Fabric für GraphQL bietet eine leistungsfähige Möglichkeit zum effizienten Abfragen von Daten, die Leistungsoptimierung ist jedoch der Schlüssel zur Sicherstellung einer reibungslosen und skalierbaren Leistung. Ganz gleich, ob Sie komplexe Abfragen verarbeiten oder Antwortzeiten optimieren, die folgenden bewährten Methoden helfen Ihnen, die beste Leistung aus Ihrer GraphQL-Implementierung zu erzielen und ihre API-Effizienz in Fabric zu maximieren.

Wer die Leistungsoptimierung benötigt

Die Leistungsoptimierung ist entscheidend für:

  • Anwendungsentwickler erstellen High-Traffic-Anwendungen, die Fabric Lakehouses und Warehouses abfragen
  • Datentechniker optimieren Fabric-Datenzugriffsmuster für umfangreiche Analyseanwendungen und ETL-Prozesse
  • Fabric-Arbeitsbereichsadministratoren , die den Kapazitätsverbrauch verwalten und eine effiziente Ressourcenauslastung sicherstellen
  • BI-Entwickler verbessern die Reaktionszeiten für benutzerdefinierte Analyseanwendungen, die auf Fabric-Daten basieren
  • DevOps-Teams behandeln Latenzprobleme in Produktionsanwendungen, die Fabric-APIs verwenden

Verwenden Sie diese bewährten Methoden, wenn Ihre GraphQL-API Produktionsworkloads effizient verarbeiten muss oder wenn Leistungsprobleme auftreten.

Bereichsausrichtung

Regionsübergreifende API-Aufrufe sind eine häufige Ursache für hohe Latenz. Stellen Sie für eine optimale Leistung sicher, dass Sich Ihre Clientanwendungen, Fabric-Mandant, Kapazität und Datenquellen in derselben Azure-Region befinden.

Überprüfen Sie Ihre Mandantenregion

So suchen Sie die Region Ihres Fabric-Mandanten:

  1. Melden Sie sich mit einem Administratorkonto beim Microsoft Fabric-Portal an.
  2. Wählen Sie das Hilfesymbol (?) in der oberen rechten Ecke aus.
  3. Wählen Sie unten im Hilfebereich "Info" die Option "Informationen zu Fabric" aus.
  4. Beachten Sie die Region, die in den Mandantendetails angezeigt wird.

Überprüfen Sie Ihre Kapazitätsregion

Ihre API für GraphQL wird innerhalb einer bestimmten Kapazität ausgeführt. So suchen Sie die Kapazitätsregion:

  1. Öffnen des Arbeitsbereichs, in dem Ihre API für GraphQL gehostet wird

  2. Wechseln Sie zu „Arbeitsbereichseinstellungen“>„Lizenzinformationen“

  3. Suchen der Region unter Lizenzkapazität

    Screenshot, der zeigt, wie Sie den Kapazitätsbereich für Ihren Arbeitsbereich abrufen.

Überprüfen Sie Ihre Datenquellenregion

Der Speicherort Ihrer Datenquellen wirkt sich auch auf die Leistung aus:

  • Fabric-Datenquellen (Lakehouse, Data Warehouse, SQL-Datenbank): Diese verwenden dieselbe Region wie die Kapazität des Arbeitsbereichs.
  • Externe Datenquellen (Azure SQL-Datenbank usw.): Überprüfen Sie den Ressourcenspeicherort im Azure-Portal.

Bewährte Methode: Bereitstellen von Clientanwendungen in derselben Region wie Ihre Fabric-Kapazität und -Datenquellen, um die Netzwerklatenz zu minimieren.

Bewährte Methoden für Leistungstests

Befolgen Sie beim Auswerten der LEISTUNG Ihrer API diese Richtlinien für zuverlässige und konsistente Ergebnisse.

Verwenden realistischer Testtools

Testen Sie tools, die eng mit Ihrer Produktionsumgebung übereinstimmen:

  • Skripts oder Anwendungen: Verwenden Von Python-, Node.js- oder .NET-Skripts, die das tatsächliche Clientverhalten simulieren
  • HTTP-Verbindungspooling: Wiederverwenden von HTTP-Verbindungen, um die Latenz zu reduzieren, besonders wichtig für regionsübergreifende Szenarien
  • Sitzungsverwaltung: Verwalten von Sitzungen über Anforderungen hinweg, um die reale Nutzung exakt widerzuspiegeln

Beispielressourcen:

Sammeln aussagekräftiger Metriken

Für eine genaue Leistungsbewertung:

  1. Automatisieren von Tests: Verwenden von Skripts oder Leistungstesttools zum konsistenten Ausführen von Tests über einen definierten Zeitraum
  2. Aufwärmen der API: Führen Sie mehrere Testabfragen aus, bevor Sie die Leistung messen (siehe Warm-up-Anforderungen)
  3. Analysieren von Verteilungen: Verwenden Sie quantilbasierte Metriken (P50, P95, P99) und nicht nur Mittelwerte, um Latenzmuster zu verstehen.
  4. Test under load: Messen der Leistung mit realistischen gleichzeitigen Anforderungsvolumes
  5. Dokumentbedingungen: Aufzeichnen der Tageszeit, Kapazitätsauslastung und aller gleichzeitigen Arbeitsauslastungen während des Tests

Allgemeine Leistungsprobleme

Wenn Sie diese häufig auftretenden Probleme verstehen, können Sie Leistungsprobleme effektiv diagnostizieren und beheben.

Anforderungen an die Aufwärmphase

Problem: Die erste API-Anforderung dauert erheblich länger als nachfolgende Anforderungen.

Warum dies geschieht:

  • API-Initialisierung: Beim Leerlauf muss die API-Umgebung während des ersten Aufrufs initialisiert werden, wodurch einige Sekunden Latenz hinzugefügt wird.
  • Aufwärmung der Datenquelle: Viele Datenquellen (insbesondere SQL Analytics-Endpunkte und Data Warehouses) durchlaufen eine Warm-up-Phase, wenn der Zugriff nach dem Leerlauf erfolgt.
  • Kombinierte Initialisierung: Wenn sowohl die API als auch die Datenquelle im Leerlauf sind, werden initialisierungszeiten zusammengesetzt.

Solution:

  • Ausführen von 2-3 Testabfragen vor dem Messen der Leistung
  • Implementieren Sie für Produktionsanwendungen Endpunkte zur Integritätsprüfung, die die API warm halten.
  • Erwägen Sie die Verwendung geplanter Abfragen oder Überwachungstools, um einen aktiven Zustand während der Geschäftszeiten aufrechtzuerhalten.

Regionale Fehlausrichtung

Problem: Konsistente hohe Latenz über alle Anforderungen hinweg.

Warum dies geschieht: Regionsübergreifende Netzwerkaufrufe fügen erhebliche Latenz hinzu, insbesondere, wenn sich der Client, die API und Datenquellen in verschiedenen Azure-Regionen befinden.

Solution:

  • Überprüfen, ob sich Ihre Clientanwendung, Fabric-Kapazität und Datenquellen in derselben Region befinden
  • Wenn der regionsübergreifende Zugriff unvermeidbar ist, implementieren Sie aggressive Caching-Strategien
  • Erwägen Sie die Bereitstellung regionaler API-Replikate für globale Anwendungen.

Leistung der Datenquelle

Problem: API-Anforderungen sind langsam, auch wenn die API aufgewärmet wird und Regionen ausgerichtet werden.

Warum dies geschieht: DIE API für GraphQL fungiert als Abfrageschnittstelle für Ihre Datenquellen. Wenn die zugrunde liegende Datenquelle Leistungsprobleme wie fehlende Indizes, komplexe Abfragen oder Ressourceneinschränkungen aufweist, erbt die API diese Einschränkungen.

Solution:

  1. Direktes Testen: Abfragen der Datenquelle direkt (mithilfe von SQL oder anderen systemeigenen Tools), um eine grundlegende Leistung herzustellen
  2. Optimieren Sie die Datenquelle:
  3. Kapazität anpassen: Stellen Sie sicher, dass Ihre Fabric-Kapazitäts-SKU ausreichende Computerressourcen bereitstellt. Anleitungen zum Auswählen der geeigneten Kapazität finden Sie in den Microsoft Fabric-Konzepten .

Abfrageentwurf

Problem: Einige Abfragen funktionieren gut, während andere langsam sind.

Warum dies geschieht:

  • Überabfrage: Das Anfordern von mehr Feldern als erforderlich erhöht die Verarbeitungszeit.
  • Tiefe Schachtelung: Abfragen mit vielen Ebenen geschachtelter Beziehungen erfordern mehrere Auflösungsausführungen.
  • Fehlende Filter: Abfragen ohne geeignete Filter können übermäßige Daten zurückgeben

Solution:

  • Fordern Sie nur die Felder an, die Sie in Ihrer GraphQL-Abfrage benötigen.
  • Begrenzen der Tiefe geschachtelter Beziehungen, sofern möglich
  • Verwenden geeigneter Filter und Paginierung in Ihren Abfragen
  • Erwägen Sie, komplexe Abfragen bei Bedarf in mehrere einfachere Abfragen zu unterteilen.