Leitfaden zu Einschränkungen in Microsoft Graph
Durch Einschränkungen wird die Anzahl gleichzeitiger Aufrufe an einen Dienst begrenzt, um eine Überlastung von Ressourcen zu verhindern. Microsoft Graph ist für die Verarbeitung einer großen Menge von Anforderungen konzipiert. Wenn die Anzahl der Anforderungen jedoch zu hoch ist und zu einer Überlastung führen könnte, tragen Einschränkungen dazu bei, die optimale Leistung und Zuverlässigkeit des Microsoft Graph-Diensts aufrechtzuerhalten.
Einschränkungsgrenzwerte variieren je nach Szenario. Wenn Sie z. B. eine große Anzahl von Schreibvorgängen ausführen, ist die Drosselungsmöglichkeit höher als bei nur Lesevorgängen.
Hinweis
Lösungen, die eine große Datenmenge aus Microsoft Graph extrahieren müssen, sollten Microsoft Graph Data Connect anstelle der Microsoft Graph-REST-APIs verwenden. Mit Microsoft Graph Data Connect können Organisationen Microsoft 365-Daten massenhaft extrahieren, ohne Einschränkungsgrenzwerten zu unterliegen.
Was passiert im Fall einer Einschränkung?
Wenn ein Drosselungsschwellenwert überschritten wird, schränkt Microsoft Graph alle weiteren Anforderungen von diesem Client für einen bestimmten Zeitraum ein. Wenn eine Drosselung auftritt, gibt Microsoft Graph HTTP-status Code 429 (Zu viele Anforderungen) zurück, und die Anforderungen schlagen fehl. Eine vorgeschlagene Wartezeit wird im Antwortheader der fehlgeschlagenen Anforderung zurückgegeben. Das Drosselungsverhalten kann vom Typ und der Anzahl der Anforderungen abhängen. Wenn Sie beispielsweise eine große Anzahl von Anforderungen haben, werden alle Anforderungstypen gedrosselt. Schwellenwerte variieren je nach Anforderungstyp. Daher kann es zu einem Szenario kommen, in dem Schreibvorgänge gedrosselt werden, lesevorgänge jedoch weiterhin zulässig sind.
Allgemeine Einschränkungsszenarien
Zu den häufigsten Ursachen für die Einschränkung von Clients zählen folgende:
- Eine große Anzahl von Anforderungen in allen Anwendungen in einem Mandanten.
- Eine große Anzahl von Anforderungen von einer bestimmten Anwendung in allen Mandanten.
Beispielantwort
Immer wenn die Drosselungsschwelle überschritten wird, antwortet Microsoft Graph mit einer ähnlichen Reaktion.
HTTP/1.1 429 Too Many Requests
Content-Length: 312
Content-Type: application/json
Retry-After: 10
{
"error": {
"code": "TooManyRequests",
"innerError": {
"code": "429",
"date": "2020-08-18T12:51:51",
"message": "Please retry after",
"request-id": "94fb3b52-452a-4535-a601-69e0a90e3aa2",
"status": "429"
},
"message": "Please retry again later."
}
}
Bewährte Methoden zum Behandeln der Einschränkungen
Im Folgenden finden Sie bewährte Methoden für den Umgang mit Einschränkungen:
- Verringern Sie die Anzahl der Vorgänge pro Anforderung.
- Verringern Sie die Häufigkeit von Aufrufen.
- Vermeiden Sie sofortige Wiederholungsversuche, da alle Anforderungen auf Ihre Nutzungsgrenzwerte angerechnet werden.
Verwenden Sie beim Implementieren der Fehlerbehandlung den HTTP-Fehlercode 429, um eine Drosselung zu erkennen. Die fehlgeschlagene Antwort enthält den Retry-After Antwortheader. Das Sichern von Anforderungen mithilfe der Retry-After Verzögerung ist die schnellste Möglichkeit, die Drosselung wiederherzustellen, da Microsoft Graph weiterhin die Ressourcennutzung protokolliert, während ein Client gedrosselt wird.
- Warten Sie die im Feld
Retry-Afterangegebene Anzahl von Sekunden. - Wiederholen Sie die Anforderung.
- Wenn die Anforderung erneut mit dem Fehlercode 429 fehlschlägt, werden Sie weiterhin gedrosselt. Verwenden Sie weiterhin die empfohlene
Retry-AfterVerzögerung, und wiederholen Sie die Anforderung, bis sie erfolgreich ist.
Alle unter dienstspezifische Limiten beschriebenen Ressourcen und APIs stellen einen Retry-After-Header bereit, sofern nicht anders angegeben ist.
Eine ausführlichere Erläuterung zum Thema „Einschränkung in der Microsoft Cloud“ finden Sie unter Throttling pattern (Einschränkungsmuster).
Hinweis
Wenn die Antwort nicht die Kopfzeile Retry-After enthält, empfehlen wir die Implementierung einer exponentiellen Backoff Retry-Richtlinie. Sie können auch erweiterte Muster implementieren, wenn Sie umfangreiche Anwendungen erstellen.
Microsoft Graph SDKs implementieren bereits Handler, die sich auf die Kopfzeile Retry-After verlassen oder standardmäßig eine exponentielle Backoff Retry-Richtlinie anwenden.
Bewährte Methoden zur Vermeidung der Drosselung
Programmiermuster wie das kontinuierliche Abfragen einer Ressource auf Aktualisierungen und das regelmäßige Scannen von Ressourcensammlungen auf neue oder gelöschte Ressourcen führen mit größerer Wahrscheinlichkeit dazu, dass Anwendungen gedrosselt werden und sich die Gesamtleistung verschlechtert. Stattdessen sollten Sie Änderungsverfolgung und Änderungsbenachrichtigungen nutzen, wenn diese verfügbar sind.
Hinweis
Bewährte Methoden zum Ermitteln von Dateien und zum Erkennen von Änderungen im großen Maßstab beschreibt detailliert die bewährten Methoden.
Drosselung und Batchverarbeitung
Mit der JSON-Batchverarbeitung können Sie Ihre Anwendung optimieren, indem Sie mehrere Anforderungen in einem einzigen JSON-Objekt kombinieren. Anforderungen in einem Batch werden einzeln anhand von Drosselungsgrenzwerten ausgewertet. Wenn eine Anforderung die Grenzwerte überschreitet, schlägt sie mit einem status Code von 429 und einem Fehler ähnlich der vorherigen Beispielantwort fehl. Der Batch selbst ist mit dem status Code (200OK) erfolgreich. Mehrere Anforderungen können in einem einzelnen Batch gedrosselt werden. Wiederholen Sie jede fehlgeschlagene Anforderung aus dem Batch unter Verwendung des Wertes im Antwortkopf retry-after aus dem JSON-Inhalt. Sie können alle fehlgeschlagenen Anforderungen in einem neuen Batch nach dem längsten retry-after-Wert wiederholen.
Wenn SDKs die gedrosselten Anforderungen automatisch wiederholen, wenn Sie nicht in der Batchverarbeitung sind, werden gedrosselte Anforderungen, die Bestandteil eines Batches waren, nicht automatisch wiederholt.