Freigeben über

Vermeiden von Einschränkungen oder Sperren in SharePoint Online

  • Artikel

In diesem Artikel erfahren Sie mehr über das Thema Drosselung (Einschränkungen) in SharePoint Online. Außerdem erläutern wir Ihnen, wie Sie eine Drosselung oder Sperre vermeiden können.

Kommt diese bekannt? Sie führen eine Anwendung aus, beispielsweise zum Überprüfen von Dateien in SharePoint Online, aber Sie werden gedrosselt. Oder sogar noch schlimmer, Sie werden gesperrt. Was geschieht, und was können Sie tun, sodass sie beenden?

Was ist Drosselung bzw. Einschränkung?

SharePoint Online verwendet die Drosselung, um die optimale Leistung und Zuverlässigkeit des SharePoint Online-Diensts aufrechtzuerhalten. Die Drosselung schränkt die Anzahl der API-Aufrufe oder -Vorgänge innerhalb eines Zeitfensters ein, um die übermäßige Nutzung von Ressourcen zu verhindern.

Was geschieht, wenn Sie in SharePoint Online gedrosselt abrufen?

Wenn Nutzungslimits überschritten werden, drosselt SharePoint Online alle weiteren Anforderungen von diesem Client für einen kurzen Zeitraum.

Bei Anforderungen, die ein Benutzer direkt im Browser ausführt, wird er von SharePoint Online zu einer Seite mit Informationen zur Einschränkung weitergeleitet. Die Anforderungen schlagen fehl.

Für Anforderungen, die eine Anwendung stellt, einschließlich Microsoft Graph, CSOM oder REST-Aufrufe, gibt SharePoint Online den HTTP-Statuscode 429 ("Zu viele Anforderungen") oder 503 ("Server zu ausgelastet") zurück, und die Anforderungen schlagen fehl.

  • HTTP 429 zeigt an, dass die aufrufende Anwendung zu viele Anforderungen innerhalb eines Zeitfensters gesendet und so einen vordefinierten Grenzwert überschritten hat.
  • HTTP 503 zeigt an, dass der Dienst nicht bereit ist, die Anforderung zu verarbeiten. Die häufige Ursache ist, dass der Dienst mehr temporäre Lastspitzen als erwartet aufweist.

In beiden Fällen enthält die Antwort einen Retry-After-Header, der anzeigt, wie lange die aufrufende Anwendung warten sollte, bevor sie es erneut versucht oder eine neue Anforderung sendet. Gedrosselte Anforderungen werden auf die Nutzungslimits angerechnet. Wenn Sie also Retry-After nicht respektierten, kann dies zu einer höheren Drosselung führen.

Wenn die problematische Anwendung weiterhin Nutzungslimits überschreitet, sperrt SharePoint Online die Anwendung oder bestimmte Anforderungsmuster der Anwendung möglicherweise vollständig. In diesem Fall erhält die Anwendung weiterhin den HTTP-Statuscode 503, und Microsoft benachrichtigt den Mandanten über die Sperre im Office 365-Nachrichtencenter.

Benutzereinschränkung

Die Drosselung beschränkt die Anzahl der Aufrufe und Vorgänge, die von Anwendungen im Namen eines Benutzers gemeinsam ausgeführt werden, um die übermäßige Nutzung von Ressourcen zu verhindern.

Trotzdem kommt es selten vor, dass ein Benutzer in Microsoft Office SharePoint Online eingeschränkt wird. Der Dienst ist sehr stabil und für große Datenvolumen ausgelegt. Wenn Sie eingeschränkt werden, liegt dies zu 99 % an benutzerdefiniertem Code, z. B. benutzerdefinierten Webparts, komplexen Listenansichten und Abfragen oder benutzerdefinierten Apps, die Benutzer ausführen. Das bedeutet nicht, dass es keine anderen Gründe gibt, eingeschränkt zu werden, nur dass sie weniger häufig sind. Beispielsweise kann ein Benutzer, der eine große Datenmenge auf 10 Computern gleichzeitig synchronisiert, eine Einschränkung auslösen.

Anwendungseinschränkung

Zusätzlich zur Drosselung nach Benutzerkonto werden Grenzwerte auch auf Anwendungen in einem Mandanten angewendet.

Jede Anwendung besitzt ihre eigenen Grenzwerte in einem Mandanten, die auf der Anzahl der pro Organisation erworbenen Lizenzen basieren (enthaltene Lizenzen finden Sie in den unter SharePoint-Grenzwerte aufgeführten Plänen). Jede Anforderung, die eine Anwendung über alle API-Endpunkte hinweg sendet, einschließlich Microsoft Graph, CSOM und REST, zählt für die Nutzung der Anwendung.

SharePoint stellt verschiedene APIs bereit. Verschiedene APIs gehen je nach Komplexität der API mit unterschiedlichen Kosten einher. Die Kosten für APIs werden von SharePoint normalisiert und durch Ressourceneinheiten ausgedrückt. Die Grenzwerte einer Anwendung werden auch mithilfe von Ressourceneinheiten definiert.

In der folgenden Tabelle sind die Grenzwerte für Ressourceneinheiten für eine Anwendung in einem Mandanten definiert:

Lizenzanzahl 0–1k 1k–5k 5k–15k 15k–50k 50k+
App 1 Minute 1.200 2.400 3.600 4.800 6.000
App täglich 1.200.000 2.400.000 3.600.000 4.800.000 6.000.000

Hinweis

Microsoft behält sich das Recht vor, die Grenzwerte für Ressourceneinheiten zu ändern.

Für mehrinstanzenfähige Anwendungen:

  1. Jeder Mandant, der die Anwendung hosten, gilt als unterschiedlich und arbeitet unabhängig von anderen. Folglich unterliegt jede Anwendung ihren eigenen Nutzungsgrenzwerten innerhalb jedes Mandanten, wie oben definiert.
  2. Der Verbrauch von Ressourceneinheiten durch die Anwendung ist pro Mandant und pro Anwendung zu messen. Dadurch wird sichergestellt, dass jedes Mandanten-/Anwendungspaar innerhalb der zulässigen Ressourcengrenzwerte bleibt, die für diesen bestimmten Mandanten angegeben sind.
  3. Wenn die Anwendung ihr Ressourcenlimit innerhalb eines Mandanten erreicht, wirkt sich dieses Ereignis nicht auf andere Instanzen der Anwendung aus, die in verschiedenen Mandanten ausgeführt werden. Die Ressourcenauslastung jedes Mandanten ist isoliert, wodurch mandantenübergreifende Auswirkungen verhindert werden.

In Bezug auf die API-Kosten weisen Microsoft Graph-APIs eine vordefinierte Ressourceneinheit pro Anforderung auf:

Ressourceneinheiten pro Anforderung Aktivitäten
1
  • Einzelelementabfrage, z. B. Element abrufen.
  • Delta mit einem Token.
  • Datei vom Laufwerkelement herunterladen
    		•
    2
  • Abfrage mehrerer Elemente, z. B. untergeordnete Elemente auflisten, außer Delta mit einem Token.
  • Erstellen, Aktualisieren, Löschen und Hochladen.
    		•
    5
  • Alle Berechtigungsressourcenvorgänge, einschließlich $expand=permissions.
    		•

    Hinweis

    Wir behalten uns das Recht vor, die API-Ressourceneinheitskosten zu ändern.

    Delta mit einem Token ist die effizienteste Methode zum Scannen von Inhalten in SharePoint, und wir sprechen ausführlicher über die bewährten Methoden zum Scannen von Anwendungen. Um Anwendungen zu unterstützen, die die Anleitungen befolgen, senken wir die Ressourceneinheitskosten von Deltaanforderungen mit einem Token auf 1 Ressourceneinheit, auch wenn es sich um eine Abfrage mit mehreren Elementen handelt. Die Deltaanforderung ohne ein Token wird als Abfrage mit mehreren Elementen betrachtet und kostet 2 Ressourceneinheiten pro Anforderung.

    Bei der Batchverarbeitung werden Anforderungen in einem Batch einzeln nach Ressourceneinheiten ausgewertet.

    CSOM und REST haben keine vordefinierten Kosten für Ressourceneinheiten und verbrauchen in der Regel mehr Ressourceneinheiten als Microsoft Graph-APIs , um die gleiche Funktionalität zu erreichen. Zusätzlich zu den Grenzwerten für Ressourceneinheiten unterliegen CSOM und REST auch anderen internen Ressourcengrenzwerten. Wenn Anwendungen ALSO CSOM und REST aufrufen, treten möglicherweise mehr Drosselung auf als die in diesem Dokument beschriebenen Grenzwerte. Es wird dringend empfohlen, nach Möglichkeit Microsoft Graph-APIs gegenüber CSOM- und REST-APIs zu wählen.

    Da Anwendungsgrenzwerte in Ressourceneinheiten angegeben sind, hängt die tatsächliche Anforderungsrate, z. B. Anforderungen pro Minute, von der API-Auswahl der Anwendung und den entsprechenden API-Ressourceneinheitenkosten ab. Im Allgemeinen können Sie die Anforderungsrate mit durchschnittlich 2 Ressourceneinheiten pro Anforderung abschätzen und die Grenzwerte für Ressourceneinheiten durch 2 dividieren, um die geschätzte Anforderungsrate zu erhalten.

    Obwohl jede Anwendung ihre Grenzen innerhalb eines Mandanten hat und Mandanten die Ausführung mehrerer Anwendungen erlauben, verwenden mehrere Anwendungen, die für denselben Mandanten ausgeführt werden, denselben Ressourcenbucket, und in seltenen Fällen kann es zu Ratenbegrenzungen kommen, wenn zu viele Anwendungen zu diesem Zeitpunkt Anforderungen senden.

    Wie behandelt man Drosselung?

    Nachfolgend finden Sie eine kurze Zusammenfassung der bewährten Methoden für die Behandlung von Drosselung:

    • Verringern der Anzahl gleichzeitiger Anforderungen
    • Vermeiden von Anforderungsspitzen
    • Auswählen von Microsoft Graph-APIs über CSOM- und REST-APIs nach Möglichkeit
    • Verwenden der HTTP-Header Retry-After und RateLimit
    • Gestalten Sie Ihren Datenverkehr so aus, dass Ihre Identität ersichtlich ist (siehe Abschnitt mit den bewährten Methoden zur Datenverkehrsausgestaltung weiter unten).

    Wie bereits erwähnt, handelt es sich bei Microsoft Graph um cloudbasierte APIs mit den neuesten Verbesserungen und Optimierungen. Im Allgemeinen verbraucht Microsoft Graph weniger Ressourcen als CSOM und REST, um die gleiche Funktionalität zu erreichen. Daher kann die Einführung von Microsoft Graph die Leistung der Anwendung verbessern und die Drosselung reduzieren.

    Wenn es bei Ihnen zu einer Drosselung kommt, setzen wir die Nutzung des HTTP-Headers Retry-After durch, um eine Mindestverzögerung zu gewährleisten, bis die Drosselung beseitigt wurde. Die RateLimit-HTTP-Header senden Ihnen frühzeitig Signale, wenn Sie sich Grenzwerten nähern, und Sie können Anforderungen präventiv reduzieren, um eine eventuelle Drosselung zu vermeiden.

    „Retry-After“-Header

    Wenn es bei Anwendungen zu einer Drosselung kommt, gibt SharePoint Online einen Retry-After-HTTP-Header in der Anforderung zurück, der in Sekunden anzeigt, wie lange die aufrufende Anwendung warten sollte, bevor sie es erneut versucht oder eine neue Anforderung sendet.

    Den HTTP-Header Retry-After zu respektieren, ist der schnellste Weg, mit einer Drosselung umzugehen, da SharePoint Online dynamisch den richtigen Zeitpunkt für einen erneuten Versuch bestimmt.

    Gedrosselte Anforderungen werden auf die Nutzungslimits angerechnet. Wenn Sie also Retry-After nicht respektierten, kann dies zu einer höheren Drosselung führen. Mit anderen Worten: Aggressive Wiederholungen wirken auf aufrufende Anwendungen ab, da die Aufrufe zwar fehlschlagen, aber dennoch auf Nutzungsgrenzwerte angerechnet werden. Das Respektieren des Retry-After HTTP-Headers stellt die kürzeste Verzögerung sicher und reduziert die Verschwendung von Kontingenten bei gedrosselten Anforderungen.

    RateLimit-Header (Vorschau)

    Zusätzlich zum Retry-After Header in der Antwort auf gedrosselte Anforderungen gibt SharePoint Online auch die IETF-RateLimit-Header für ausgewählte Grenzwerte unter bestimmten Bedingungen zurück, um Anwendungen bei der Verwaltung der Ratenbegrenzung zu unterstützen. Wir empfehlen, Anwendungen diese Header nutzen zu lassen, um Drosselungen zu vermeiden.

    • RateLimit-Limit enthält den Grenzwert im aktuellen Zeitfenster.
    • RateLimit-Remaining zeigt das verbleibende Kontingent im aktuellen Fenster an.
    • RateLimit-Reset zeigt die Anzahl der verbleibenden Sekunden an, bis das Kontingent nachgefüllt wird.

    Hinweis

    Diese Header befinden sich derzeit in der Betaversion und können sich jederzeit ändern. Zum Zeitpunkt der Einführung der Header befand sich die IETF-Spezifikation noch im Entwurfsstadium. Die aktuelle Implementierung basiert auf draft-03 der IETF-Spezifikation. Es besteht die Möglichkeit von Änderungen, wenn die Spezifikation abgeschlossen ist, und wir werden diese Änderungen in Zukunft übernehmen.

    Die RateLimit-Header werden nach dem Best Effort-Prinzip zurückgegeben, sodass Anwendungen die Kopfzeilen möglicherweise nicht unter allen Umständen erhalten. Darüber hinaus gibt es weitere Grenzwerte, die nicht in den RateLimit-Headern angezeigt werden, weshalb Anwendungen sogar gedrosselt werden können, bevor sie den in den RateLimit-Headern beschriebenen Grenzwert erreicht haben. Nachfolgend finden Sie eine Liste der Grenzwerte, für die wird die RateLimit-Header unterstützen. Die Richtlinien und Werte können sich jederzeit ändern:

    Begrenzung Bedingung Grenzwert Beschreibung
    App-Ressourceneinheit für 1 Minute Nutzung >= 80 % des Grenzwerts Ressourceneinheit Wenn eine Anwendung 80 % oder mehr ihres App-1-Minuten-Grenzwerts verbraucht, werden der Grenzwert, der Verbleibende und das Zurücksetzen zurückgegeben.

    Im Folgenden finden Sie einige Beispiele, die Ihnen helfen, die RateLimit-Header zu verstehen:

    • Eine Anwendung hat 90 % ihres Ressourceneinheitskontingents (1.080 von 1.200) verbraucht, und ihr Verbrauch liegt innerhalb aller für sie geltenden Grenzwerte. Die Anforderung ist erfolgreich, und die RateLimit-Header werden zurückgegeben.
    HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5
    • Eine Anwendung hat 100 % ihres Ressourceneinheitskontingents verbraucht, weshalb sie durch diese Richtlinie gedrosselt wird. Die Anforderung wird gedrosselt, und die RateLimit-Header werden zurückgegeben. Retry-After stimmt mit RateLimit-Reset überein.
    HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31
    • Eine Anwendung hat 90 % ihres Ressourceneinheitskontingents verbraucht, aber ihr Verbrauch hat bereits andere Grenzwerte erreicht, die von den RateLimit-Headern nicht unterstützt werden. In diesem Fall wird die Anforderung gedrosselt, und die RateLimit-Header werden nicht zurückgegeben, um Verwirrung zu vermeiden, obwohl die Bedingung für das Zurückgeben der Header erfüllt ist.
    HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Weitere Informationen finden Sie unter Verhindern der Drosselung in Ihrer Anwendung mithilfe von RateLimit-Headern in SharePoint Online.

    Wie können Sie Ihren HTTP-Datenverkehr ergänzen?

    Korrekt ausgestalteter Datenverkehr hat Vorrang vor nicht korrekt ausgestaltetem Datenverkehr.

    Wann gilt Datenverkehr als nicht ausgestaltet?

    • Datenverkehr gilt als nicht ausgestaltet, wenn API-Aufrufe an SharePoint Online die Zeichenfolgen „AppID“/„AppTitle“ und „UserAgent“ nicht enthalten. Die User-Agent Zeichenfolge sollte in einem bestimmten Format vorliegen, wie unten beschrieben.
    • Wenn Sie eine Webanwendung entwickeln, die im Browser ausgeführt wird, gestatten die meisten modernen Browser kein Überschreiben der UserAgent-Zeichenfolge, weshalb Sie sie nicht implementieren müssen.

    Nach welchen Empfehlungen sollte ich mich richten?

    • Wenn Sie eine Anwendung erstellt haben, empfiehlt es sich, „AppID“ und „AppTitle“ zu registrieren und zu verwenden. Dies gewährleistet die beste Gesamterfahrung und den besten Weg für jede zukünftige Problemlösung. Schließen Sie auch die Zeichenfolgeninformationen des Benutzer-Agents ein, wie im folgenden Schritt definiert.

      Hinweis

      Informationen zum Erstellen einer Azure AD-Anwendung finden Sie in der Microsoft Identity-Dokumentation, z. B. auf der Seite Schnellstart: Registrieren einer Anwendung bei der Microsoft Identity Platform.

    • Stellen Sie sicher, dass Sie die User-Agent-Zeichenfolge in Ihren API-Aufruf von SharePoint mit der folgenden Namenskonvention einschließen.

    Typ Benutzer-Agent Beschreibung
    ISV-Anwendung ISV|CompanyName|AppName/Version Identifizieren Sie sich als ISV, und fügen Sie Den Firmennamen und den App-Namen durch ein Pipezeichen getrennt ein, und fügen Sie dann versionsnummer durch einen Schrägstrich getrennt hinzu.
    Unternehmensanwendung NONISV|CompanyName|AppName/Version Diese Zeichenfolge identifiziert Sie als „NONISV“ und enthält den Namen Ihres Unternehmens sowie den Namen der App, alles jeweils getrennt durch einen senkrechten Strich und gefolgt von einem Schrägstrich und der Versionsnummer.
    • Wenn Sie Ihre eigenen JavaScript-Bibliotheken erstellen, die zum Aufrufen von SharePoint Online-APIs verwendet werden, stellen Sie sicher, dass Sie die User-Agent Informationen in Ihre HTTP-Anforderung einschließen und Ihre Webanwendung ggf. auch als Anwendung registrieren.

    Hinweis

    Es wird erwartet, dass das Format der Benutzer-Agent-Zeichenfolge RFC2616 folgt. Befolgen Sie daher die obige Anleitung zu den rechten Trennzeichen. Es ist auch in Ordnung, die vorhandene Benutzer-Agent-Zeichenfolge mit den angeforderten Informationen anzufügen.

    Allgemeine Einschränkungsszenarien in SharePoint Online

    Die häufigsten Ursachen für Drosselungen in SharePoint Online pro Benutzer werden mithilfe der clientseitigen Objektmodell (CSOM) oder Representational State Transfer (REST) Code, der zu häufig zu viele Aktionen ausführt.

    • Gelegentlicher Datenverkehr

      Eine konstante Auslastung oder sich wiederholenden komplexe Abfragen in SharePoint Online müssen für geringe Auswirkungen optimiert werden. Wenn Sie nicht die bewährten Methoden zum Überprüfen von Anwendungen befolgen, die Dateien massenverarbeiten, führt dies mit großer Wahrscheinlichkeit zu Einschränkungen. Zu diesen Apps gehören Synchronisierungs-Engines, Sicherungsanbieter, Suchindexer, Klassifizierungs-Engines, Tools zur Verhinderung von Datenverlust und jedes andere Tool, das versucht, die Gesamtheit der Daten zu ermitteln und Änderungen darauf anzuwenden.

    • Overwhelming Datenverkehr

      Ein einzelner Prozess überschreitet die Drosselungsgrenzen über einen längeren Zeitraum kontinuierlich.

      • Sie verwendet Webdienste zum Erstellen eines Tools zum Synchronisieren von Benutzerprofileigenschaften haben. Das Tool aktualisiert Benutzerprofileigenschaften basierend auf Informationen aus der Line-of-Business (LOB) Personalabteilung (HR)-System. Das Tool führt Aufrufe Zeitabständen zu hoch.
      • Sie führen ein Lasttest-Skript auf Microsoft Office SharePoint Online aus und werden gedrosselt. Auslastungstests sind auf Microsoft Office SharePoint Online nicht zugelassen.
      • Sie haben Ihre Teamwebsite auf SharePoint Online, beispielsweise durch Hinzufügen einer Statusanzeige auf der Homepage angepasst. Dieser Statusindikator aktualisiert häufig, die bewirkt, dass der Seite zu viele Aufrufe an den Dienst SharePoint Online - dieser Einschränkung ausgelöst.
      • Das Ausführen des OneDrive-Synchronisierungsclients beim gleichzeitigen Ausführen von Migrationsanwendungen oder Anwendungen, die Websites durchforsten und Daten zurückschreiben, kann zu hohen Anforderungsvolumen führen, die möglicherweise eine Drosselung auslösen.

    • Nicht unterstützte Anwendungsfälle

      Bei einer nicht unterstützten Verwendung von SharePoint Online kann es zu Einschränkungen kommen. Die Verwendung von SharePoint und OneDrive als Zwischendienst zwischen Microsoft 365 und einem anderen Repository ist ein Beispiel für einen nicht unterstützten Anwendungsfall.

    • Mehrere AppIDs für dieselbe Anwendung erstellen

      Erstellen Sie keine separaten AppIDs, wenn die Anwendungen im Wesentlichen dieselben Vorgänge ausführen, z. B. Sicherung oder Verhinderung von Datenverlust. Anwendungen, die für denselben Mandanten ausgeführt werden, nutzen letztendlich dieselbe Ressource wie der Mandant. In der Vergangenheit hatten einige Anwendungen diesen Ansatz, um die Anwendungsdrosselung zu umgehen. Dies führte jedoch dazu, dass die Ressourcen des Mandanten erschöpft waren und mehrere Anwendungen im Mandanten gedrosselt wurden.

    Szenariospezifische Grenzwerte

    Bei Verwendung der reinen App-Authentifizierung mit der Berechtigung „Sites.Read.All“.

    Wenn Sie SharePoint Online-Such-APIs mit nur app-Authentifizierung verwenden und die App über die Berechtigung Sites.Read.All (oder stärker) verfügt, wird die App mit vollständigen Berechtigungen registriert und darf alle SharePoint Online-Inhalte (einschließlich der privaten OneDrive for Business-Inhalte des Benutzers) abfragen.

    Um sicherzustellen, dass der Dienst schnell und zuverlässig bleibt, werden Abfragen mit einer solchen Berechtigung auf 25 Anforderungen pro Sekunde gedrosselt. Die Suchabfrage gibt eine HTTP 429-Antwort zurück. Während des Wartens auf die Wiederherstellung von einer Drosselung sollten Sie alle Suchabfrageanforderungen anhalten, die Sie möglicherweise mittels ähnlicher reiner App-Genehmigungen an den Dienst senden. Das Ausführen weiterer Aufrufe, während Sie Drosselungsantworten erhalten, verlängert den Zeitraum, den es benötigt, bis die Drosselung Ihrer Anwendung aufgehoben wird.

    Bei der Suche mit delegierten Benutzerberechtigungen

    Die Suche mit delegierten Benutzerberechtigungen erfolgt, wenn eine Anwendung eine Suchabfrageanforderung mit den Berechtigungen des angemeldeten Benutzers sendet. Beispiele für delegierte Anforderungen sind: das Suchfeld auf einer SharePoint-Seite, ein suchbasiertes Webpart oder eine benutzerdefinierte Anwendung, die auf einer SharePoint-Seite eingebettet ist, und eine Power Automate-Workflowabfrage nach Elementinformationen.

    Um die Dienststabilität sicherzustellen, drosselt der Dienst delegierte Benutzeranforderungen, die 10 Anforderungen pro Sekunde pro Benutzer überschreiten. Dieser Benutzergrenzwert aggregiert alle Anforderungen von allen Apps. Wenn ein einzelner Benutzer mehr als 10 Suchabfrageanforderungen pro Sekunde sendet, wird http 429 zurückgegeben. Die anfordernde Anwendung sollte die Dauer des im Antwortheader angegebenen Timeouts warten, bevor nachfolgende Anforderungen gesendet werden. Beim Entwerfen suchbasierter Anwendungen, SharePoint-Seiten und Workflows sollten Implementierer sicherstellen, dass seite und Anwendung 10 Anforderungen pro Sekunde im Aggregat nicht überschreiten und 429 Drosselungsantworten verarbeiten. Weitere Informationen und Anleitungen zum Seitendesign und zur Suchoptimierung finden Sie unter Optimieren von Suchanforderungen auf modernen SharePoint Online-Websiteseiten und Verwenden des Seitendiagnosetools für SharePoint Online.

    Bei der Suche nach Suchergebnissen für Personen

    Bei der Suche mithilfe einer Ergebnisquelle, die Personenergebnisse anfordert, können wir alle Anforderungen drosseln, die einen organisationsweiten Grenzwert von 25 Anforderungen pro Sekunde überschreiten. Dieser Grenzwert gilt für alle SHAREPoint-Such-CSOM- und REST-Anforderungen, die entweder die vordefinierte Ergebnisquelle "Ergebnisse lokaler Personen" oder eine benutzerdefinierte Ergebnisquelle für die Personensuche verwenden.

    Wenn Sie über Anwendungen oder Komponenten verfügen, die dazu führen, dass Ihre Personensuchanforderungen gedrosselt werden, empfehlen wir Folgendes:

    1. Überlegen Sie, ob die Anforderungen für Ihre Anwendung notwendig sind. Wenn Sie z. B. eine benutzerdefinierte Suchwebsite verwenden, die viele gleichzeitige Abfragen vornimmt, überprüfen Sie, ob einige dieser Anforderungen ohne erhebliche Auswirkungen auf die Sucherfahrung Ihrer Organisation entfernt werden können. Alternativ können Sie unsere moderne Personensuche in Microsoft Search ausprobieren, indem Sie auf der SharePoint-Startseite suchen. Die Personensuche in Microsoft Search wurde für bessere Leistung und relevantere Ergebnisse optimiert.
    2. Vermeiden Sie gleichzeitige Anfragen. Anstatt z. B. 10 Anforderungen gleichzeitig auszugeben, stellen Sie sie nacheinander aus, und geben Sie erst die nächste Abfrage aus, nachdem die vorherige abgeschlossen wurde. Möglicherweise müssen Sie erwägen, diese Ergebnisse zwischenzuspeichern, wenn Sie sie schnell benötigen, beispielsweise beim Laden einer Seite.
    3. Versuchen Sie, die Anforderungen in einer einzigen Abfrage zu konsolidieren. Anstatt beispielsweise 10 gleichzeitige Abfragen für WorkEmail:user1@constoso.com, WorkEmail:user2@constoso.com,..., WorkEmail:user10@contoso.comauszuführen, probieren Sie die einzelne Abfrage aus WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Erwägen Sie die Verwendung der Microsoft Graph-API, wenn ein Szenario mit hohem Anforderungsvolumen (über 25 Anforderungen pro Sekunde) wirklich erforderlich ist.

    Beim Zugriff auf OneDrive-Websites

    Wenn ein Client übermäßige Versuche unternimmt, auf viele OneDrive-Websitesammlungen zuzugreifen, die nicht vorhanden sind, können Anforderungen von der IP-Adresse dieses Clients gedrosselt werden. Der Client erhält eine HTTP 429-Antwort, wenn er während des Drosselungszeitraums auf eine OneDrive-Websitesammlung zugreift.

    Was sollten Sie tun, wenn Sie in SharePoint Online blockiert werden?

    Sperren stellen die äußerste Form von Einschränkung dar. Wir blockieren selten einen Mandanten, es sei denn, wir erkennen langfristigen, übermäßigen Datenverkehr, der die allgemeine Integrität des SharePoint Online-Diensts gefährden kann. Sperren werden angewendet, um zu verhindern, dass dieser Datenverkehr die Leistung und Zuverlässigkeit von SharePoint Online beeinträchtigt. Eine Sperre, die in der Regel auf App- oder Benutzerebene verhängt wird, verhindert, dass der fehlerhafte Prozess ausgeführt wird – bis das Problem behoben ist. Wenn Ihr Abonnement gesperrt wird, müssen Sie aktiv werden, um die problematischen Prozesse zu ändern. Erst dann kann die Sperre entfernt werden.

    Wenn wir Ihr Abonnement sperren, werden wir Sie im Nachrichtenzentrum von Office 365 über die Sperrung informieren. In der Nachricht wird beschrieben, was die Sperre verursacht. Die Nachricht enthält außerdem Anleitungen zum Beheben des Problems und teilt Ihnen mit, an wen Sie sich wenden können, um die Sperre zu entfernen.

    Siehe auch