Freigeben über

Leitfaden zur Drosselung | Graph-API-Konzepte

  • Artikel

Wichtig

Es wird dringend empfohlen, für den Zugriff auf Azure Active Directory-Ressourcen Microsoft Graph zu verwenden, nicht die Azure AD Graph-API. Wir konzentrieren unsere Entwicklungsarbeit auf Microsoft Graph, weitere Verbesserungen für die Azure AD Graph-API sind nicht geplant. Es gibt einige wenige Szenarien, in denen die Azure AD Graph-API möglicherweise noch geeignet ist. Weitere Informationen finden Sie im Office Dev Center im Blogbeitrag Microsoft Graph or the Azure AD Graph.

Was ist Drosselung?

Die Drosselung beschränkt die Anzahl gleichzeitiger Aufrufe eines Diensts, um eine übermäßige Ressourcennutzung zu verhindern. Azure AD Graph (Active Directory) ist für die Verarbeitung einer sehr hohen Anzahl von Anforderungen konzipiert. Wenn übermäßig viele Anforderungen eingehen, hilft die Drosselung dabei, die optimale Leistung und Zuverlässigkeit des Azure AD Graph-Diensts sicherzustellen.

Die Grenzwerte für die Drosselung variieren je nach Szenario. Wenn Sie z.B. sehr viele Schreibvorgänge für Ihren Mandanten durchführen, ist die Wahrscheinlichkeit einer Drosselung größer als bei Lesevorgängen.

Was passiert bei der Drosselung?

Wenn ein Drosselungsschwellenwert überschritten wird, schränkt Azure AD Graph alle weiteren Anforderungen von diesem Client ein, solange die Drosselung aktiv ist. Bei aktiver Drosselung gibt Azure AD Graph den HTTP-Statuscode 429 („Zu viele Anforderungen“) zurück, und bei den Anforderungen tritt ein Fehler auf. Das Verhalten der Drosselung kann von der Art und Anzahl der Anforderungen abhängen. Wenn z.B. eine sehr hohe Anzahl von Anforderungen vorliegt, werden alle Anforderungstypen gedrosselt. Die Schwellenwerte variieren je nach Anforderungstyp. Daher kann es passieren, dass Schreibvorgänge gedrosselt werden, Lesevorgänge aber weiterhin zulässig sind.

Häufige Szenarien für die Drosselung

Hier finden Sie einige der häufigsten Ursachen für die Drosselung von Clients:

  • Es werden sehr viele Anforderungen für alle Anwendungen in einem Mandanten gesendet.
  • Eine bestimmte Anwendung sendet über alle Mandanten hinweg sehr viele Anforderungen.

Bewährte Methoden zum Behandeln der Drosselung

  • Reduzieren der Anzahl von Vorgängen pro Anforderung.
  • Reduzieren der Häufigkeit von Aufrufen.
  • Wenn Anforderungen den HTTP-Fehlercode 429 erhalten, warten Sie so viele Sekunden wie im Retry-After-Antwortheaderfeld angegeben, und wiederholen Sie die Anforderung.

Verwenden Sie beim Implementieren der Fehlerbehandlung den HTTP-Fehlercode 429, um eine vorhandene Drosselung zu ermitteln. Die fehlerhafte Antwort enthält im Antwortheader das Feld Retry-After.

  1. Warten Sie so viele Sekunden, wie im Feld Retry-After angegeben ist.
  2. Versuchen Sie die Anforderung erneut.
  3. Wenn die Anforderung erneut den Fehlercode 429 erhält, ist die Drosselung noch aktiv. Wiederholen Sie die Anforderung nach dem in „Retry-After“ empfohlenen Zeitraum so lange, bis sie erfolgreich ist.

Das Zurücksetzen von Anforderungen mithilfe der Retry-After-Verzögerung ist die schnellste Möglichkeit, nach einer Drosselung zum Normalbetrieb zurückzukehren, da AAD Graph die Ressourcennutzung weiter protokolliert, auch wenn ein Client gedrosselt ist. Vermeiden Sie sofortige Wiederholungsversuche, da alle Anforderungen in Ihre Nutzungsmessung einfließen.

Eine umfassende Erläuterung der Drosselung in der Microsoft Cloud finden Sie unter Throttling Pattern (Drosselungsmuster).