Drosselungen und Sperren in SharePoint Online vermeiden

Erfahren Sie mehr über die Drosselung in SharePoint Online, und erfahren Sie, wie Sie vermeiden, gedrosselt oder blockiert zu werden. Dies enthält CSOM (Client-Side Object Model)- und REST-Beispielcode, den Sie verwenden können, um Ihre Aufgabe zu erleichtern.

Kommt Ihnen das bekannt vor? Sie führen einen CSOM-Prozess aus – zum Beispiel zur Migration von Dateien in Microsoft Office SharePoint Online – aber Sie werden immer wieder gedrosselt. Oder noch schlimmer, Sie werden blockiert. Was ist los, und was können Sie tun, um dies zu unterbinden?

Was ist Drosselung bzw. Einschränkung?

SharePoint Online verwendet Einschränkung, um eine optimale Leistung und Zuverlässigkeit des Diensts SharePoint Online verwalten. Einschränkungsgrenzwerte Ruft die Anzahl von Aktionen eines Benutzers oder gleichzeitige (von Code- oder Skriptblock), um Ressourcen zu verhindern.

Allerdings ist es selten, dass Benutzer in SharePoint Online gedrosselt werden. Der Dienst ist robust und so entworfen, dass er große Mengen verarbeiten kann. Wenn Sie gedrosselt werden, ist es in 99 % der Fälle durch ein benutzerdefinierten Code verursacht. Dies bedeutet nicht, dass keine anderen Gründe gibt, warum es zur Drosselung kommen kann – es bedeutet nur, dass diese weniger häufig vorkommen. Beispielsweise, wenn Sie 10 Computer hochfahren und einen Synchronisation-Client auf alle 10 haben. Bei jeder Synchronisierung 1TB an Inhalten. Dies führt wahrscheinlich dazu, dass Sie gedrosselt werden.

Wie es zu Einschränkungen kommt

Was geschieht, wenn Sie in SharePoint Online gedrosselt abrufen?

Wenn ein Benutzer Einschränkungen überschreitet, anforderungsdrosselungen SharePoint Online keine weiteren Anforderungen von mit dem Benutzerkonto für kurze Zeit. Alle Benutzeraktionen Drosselungen während der Drosselung aktiviert ist.

  • 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 alle anderen Anforderungen, einschließlich CSOM- oder REST-Aufrufen, gibt SharePoint Online den HTTP-Statuscode 429 („zu viele Anforderungen“) oder 503 („Server ausgelastet) zurück, und die Anforderungen schlagen fehl.

Wenn der fehlerhafte Prozess weiterhin die Nutzungsgrenzen überschreitet, blockiert Microsoft Office SharePoint Online den Prozess möglicherweise vollständig; in diesem Fall werden keine erfolgreichen Anfragen angezeigt, und Microsoft benachrichtigt Sie über die Blockierung im Office 365-Nachrichtencenter.

Anwendungseinschränkung

Zusätzlich zur Drosselung nach Benutzerkonto können Einschränkungen auch auf jede Anwendung einem Mandanten angewendet werden. Jede Anwendung in SharePoint Online verfügt über eine eigene Ressourcen pro Mandanten, aber mehrere Anwendungen, die im selben Mandanten ausgeführt werden, teilen sich letztendlich denselben Ressourcenbucket; dies kann in seltenen Fällen zu einer Begrenzung der Datenübertragungsrate führen. In diesen Fällen versucht SharePoint Online, interaktive Benutzeranforderungen anstelle von Hintergrundaktivitäten zu priorisieren.

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 Synchronisierungsmodule, Sicherungsanbieter, Indexerstellungen für die Suche, Klassifizierungsmodule, Tools zur Verhinderung von Datenverlust sowie andere Tools, die versuchen, die gesamten Daten und Änderungen daran zu verarbeiten.

    Nach dem Migrieren von Dateien zu SharePoint Online können Sie beispielsweise ein benutzerdefiniertes CSOM- oder REST-Skript ausführen, um Metadaten für die Dateien zu aktualisieren. Das CSOM/REST-Skript aktualisiert eine große Anzahl von Dateien mit einer hohen Frequenz, was eine Drosselung auslöst. In ähnlicher Weise kann auch ein AutoVervollständigen-UI-Widget mit REST-Diensten, das während jeder Endbenutzer-Operation zu viele Aufrufe an Listen vornimmt, eine Drosselung verursachen, je nachdem, welche anderen Vorgängen zur gleichen Zeit Ressourcen beanspruchen.

    Sporadische Einschränkung

  • Overwhelming Datenverkehr

    Ein einzelner Prozess überschreitet erheblich Drosselung Grenzwerte ständig, über einen längeren Zeitraum Zeitraum.

    • 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 SharePoint Online aus und werden gedrosselt. Lasttests sind auf SharePoint Online nicht erlaubt.

    • 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.

      Stabile Einschränkung der maximalen Bandbreite

  • 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, verwenden letztendlich dieselbe Ressource des Mandanten. 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.

Warum teilt können nicht Sie nur die Grenzwerte für die genauen Drosselung mir?

Die Festlegung und Veröffentlichung exakter Drosselungsgrenzen klingt einfach, würde aber in Wirklichkeit zu restriktiveren Grenzwerten führen. Wir überwachen den Ressourceneinsatz in SharePoint Online kontinuierlich. Je nach Verwendung optimieren wir Schwellenwerte, damit Benutzer die maximale Anzahl von Ressourcen verwenden können, ohne dass die Zuverlässigkeit und Leistung von SharePoint Online beeinträchtigt wird. Anwendungsbegrenzungen werden basierend auf dem Gesamtbenutzerdatenverkehr, der Verwendung und einigen anderen Faktoren des Mandanten festgelegt.

Deshalb ist es so wichtig, dass Ihr Code den HTTP-Header-Wert Retry-After berücksichtigt. So kann Ihr Code an jedem beliebigen Tag so schnell wie möglich ausgeführt werden, und er kann „gerade genug“ verlangsamen, wenn er auf Drosselungsgrenzen stößt. Die Codebeispiele, die weiter unten in diesem Artikel gezeigt werden, zeigen Ihnen, wie Sie die Retry-After-HTTP-Kopfzeile verwenden.

Volumengrenzwerte für Suchabfragen bei Verwendung der reinen App-Authentifizierung mit der Berechtigung "Sites.Read.All"

In SharePoint und OneDrive werden mehrere Millionen Dokumente verarbeitet und es wird unseren Kunden ermöglicht, große Abfragemengen pro Sekunde zu erstellen. Wenn Sie SharePoint Online-Such-APIs mit reiner App-Authentifizierung verwenden und eine App über Sites.Read.All -Berechtigungen (oder höher) verfügt, wird diese App mit vollständigen Berechtigungen registriert und darf alle SharePoint Online-Inhalte (einschließlich der privaten ODB-Inhalte des Benutzers) abfragen.

Wir möchten unsere Kunden darauf hinweisen, dass SharePoint Online-Suchabfragen, bei denen diese Berechtigung verwendet wird, auf 25 QPS (Abfragen pro Sekunde) gedrosselt werden. Auf die Suchabfrage wird eine 429-Antwort zurückgegeben, und Sie können die Abfrage nach 2 Minuten wiederholen. Während des Wartens auf einen 429-Neuversuch sollten alle Suchabfrageanforderungen angehalten werden, die evtl. mithilfe ähnlicher reiner App-Genehmigungen an den Dienst gestellt werden. Das Ausführen zusätzlicher Aufrufe beim Erhalt von Drosselungsantworten führt dazu, dass es noch länger dauert, bis die Drosselung der Anwendung aufgehoben wird.

Wir skalieren unser System und sind uns bewusst, wie wichtig es ist, es zu verstärken, damit es effizient ausgeführt wird und geschützt ist. Dies ist der Grund für diese Änderung. Das Rollout dieser Änderung wird für Mandanten voraussichtlich von August bis Herbst 2020 erfolgen.

Bewährte Methoden zur Handhabung der Einschränkungen

  • Reduzieren Sie die Anzahl der Vorgänge pro Anforderung
  • Reduzieren Sie die Aufrufhäufigkeit.
  • Wählen Sie wenn möglich Microsoft Graph-APIs anstelle von CSOM- und REST-APIs
  • Gestalten Sie Ihren Datenverkehr so aus, dass Ihre Identität ersichtlich ist (siehe Abschnitt mit den bewährten Methoden zur Datenverkehrsausgestaltung weiter unten).
  • Nutzung des HTTP-Headers Retry-After

Microsoft Graph sind Cloud-basierte APIs mit den neuesten Verbesserungen und Optimierungen. Im Allgemeinen verbraucht Microsoft Graph weniger Ressourcen als CSOM und REST, um die gleiche Funktionalität zu erzielen. Daher kann die Verwendung von Microsoft Graph die Leistung der Anwendung verbessern und die Drosselung verringern.

Wenn Sie auf eine Drosselung stoßen, müssen wir den HTTP-Header Retry-After nutzen, um eine minimale Verzögerung bis zum Entfernen der Drosselung zu gewährleisten.

Der HTTP-Header Retry-After ist der schnellste Weg, mit einer Drosselung umzugehen, da SharePoint Online dynamisch den richtigen Zeitpunkt für einen erneuten Versuch bestimmt. Mit anderen Worten, zu häufige Wiederholungen sind kontraproduktiv, da trotz Fehlschlagen der Aufrufe diese auf Ihre Nutzungsgrenzwerte angerechnet werden. Durch Verwendung des HTTP-Headers Retry-After wird für die kürzeste Verzögerung gesorgt.

Informationen über Möglichkeiten zur Überwachung Ihrer Microsoft Office SharePoint Online-Aktivität finden Sie unter Diagnostizieren von Leistungsproblemen bei Microsoft Office SharePoint-Online.

Eine ausführlichere Erläuterung zum Thema Einschränkung in der Microsoft Cloud finden Sie unter Drosselungsmuster.

Ausgestalten von HTTP-Datenverkehr zur Vermeidung von Drosselung

Unter Umständen wird bestimmter Datenverkehr gedrosselt, um hohe Verfügbarkeit sicherzustellen. Gedrosselt wird, wenn die Systemintegrität gefährdet ist. Ein Kriterium für die Drosselung ist dabei die Ausgestaltung des Datenverkehrs. Sie wirkt sich unmittelbar auf die Datenverkehrspriorisierung aus. Korrekt ausgestalteter Datenverkehr hat Vorrang vor nicht korrekt ausgestaltetem Datenverkehr.

Wann gilt Datenverkehr als nicht ausgestaltet?

  • Datenverkehr gilt als nicht ausgestaltet, wenn im SharePoint-Aufruf der CSOM-API oder der REST-API keine Zeichenfolge des Typs „AppID“/„AppTitle“ und des Typs „UserAgent“ enthalten ist. Die Zeichenfolge des Benutzer-Agenten sollte in einem bestimmten Format, wie nachstehend beschrieben, vorliegen.

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. Fügen Sie auch die Zeichenfolgeninformationen des Benutzeragenten 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.

  • Verwenden Sie für die Zeichenfolge des Benutzer-Agenten im API-Aufruf auf jeden Fall die folgende Namenskonvention:

Typ Benutzer-Agent Beschreibung
ISV-Anwendung ISV|CompanyName|AppName/Version Diese Zeichenfolge identifiziert Sie als „ISV“ 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.
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 Benutzer-Agent-Informationen in Ihre HTTP-Anforderung aufnehmen und Ihre Webanwendung gegebenenfalls auch als Anwendung registrieren.

Hinweis

Das Format der Benutzerer-Agent-Zeichenfolge muss dem Standard RFC2616 entsprechen. Informieren Sie sich also über die korrekten Trennzeichen. Sie können die erforderlichen Informationen auch an bereits vorhandene Benutzer-Agent-Zeichenfolgen anfügen.

Hinweis

Wenn Sie Front-End-Komponenten entwickeln, die im Browser ausgeführt werden, lassen die meisten gängigen Browser das Überschreiben der Benutzer-Agent-Zeichenfolge nicht zu und Sie müssen dies nicht implementieren.

Beispiel für die Ausgestaltung von Datenverkehr mit einem Benutzer-Agenten bei Verwendung des clientseitigen Objektmodells (CSOM)

// Get access to source site
using (var ctx = new ClientContext("https://contoso.sharepoint.com/sites/team"))
{
  //Provide account and pwd for connecting to SharePoint Online
  var passWord = new SecureString();
  foreach (char c in pwd.ToCharArray()) passWord.AppendChar(c);
  ctx.Credentials = new SharePointOnlineCredentials("contoso@contoso.onmicrosoft.com", passWord);

  // Add our User Agent information
  ctx.ExecutingWebRequest += delegate (object sender, WebRequestEventArgs e)
  {
      e.WebRequestExecutor.WebRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
  };

  // Normal CSOM Call with custom User-Agent information
  Web site = ctx.Web;
  ctx.Load(site);
  ctx.ExecuteQuery();
}

Beispiel für die Ausgestaltung von Datenverkehr mit einem Benutzer-Agenten bei Verwendung von REST-APIs

Im folgenden Beispiel wird das C#-Format verwendet. Es empfiehlt sich jedoch, die ähnlichen Benutzer-Agent-Informationen auch für die JavaScript-Bibliotheken zu nutzen, die auf den SharePoint Online-Seiten verwendet werden.

HttpWebRequest endpointRequest = (HttpWebRequest) HttpWebRequest.Create(sharepointUrl.ToString() + "/_api/web/lists");
endpointRequest.Method = "GET";
endpointRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
endpointRequest.Accept = "application/json;odata=nometadata";
endpointRequest.Headers.Add("Authorization", "Bearer " + accessToken);
HttpWebResponse endpointResponse = (HttpWebResponse)endpointRequest.GetResponse();

CSOM-Codebeispiel: ExecuteQueryWithIncrementalRetry-Erweiterungsmethode

Hinweis

Sie müssen SharePoint Online, CSOM-Version 16.1.8316.1200 (Version vom Dezember 2018) oder höher verwenden.

Fügen Sie diese Erweiterungsmethode in einer statischen Klasse hinzu, und verwenden Sie ExecuteQueryWithIncrementalRetry anstelle von ExecuteQuery, damit Ihr Code Einschränkungsanfragen verarbeiten kann.

public static void ExecuteQueryWithIncrementalRetry(this ClientContext clientContext, int retryCount)
{
  int retryAttempts = 0;
  int retryAfterInterval = 0;
  bool retry = false;
  ClientRequestWrapper wrapper = null;
  if (retryCount <= 0)
  {
    throw new ArgumentException("Provide a retry count greater than zero.");
  }

  // Do while retry attempt is less than retry count
  while (retryAttempts < retryCount)
  {
    try
    {
      if (!retry)
      {
        clientContext.ExecuteQuery();
        return;
      }
      else
      {
        //increment the retry count
        retryAttempts++;

        // retry the previous request using wrapper
        if (wrapper != null && wrapper.Value != null)
        {
          clientContext.RetryQuery(wrapper.Value);
          return;
        }
        // retry the previous request as normal
        else
        {
          clientContext.ExecuteQuery();
          return;
        }
      }
    }
    catch (WebException ex)
    {
        var response = ex.Response as HttpWebResponse;
        // Check if request was throttled - http status code 429
        // Check is request failed due to server unavailable - http status code 503
        if (response != null && (response.StatusCode == (HttpStatusCode)429 || response.StatusCode == (HttpStatusCode)503))
        {
          wrapper = (ClientRequestWrapper)ex.Data["ClientRequest"];
          retry = true;

          // Determine the retry after value - use the `Retry-After` header
          retryAfterInterval = Int32.Parse(response.GetResponseHeader("Retry-After"));

          // Delay for the requested seconds
          Thread.Sleep(retryAfterInterval * 1000);
        }
        else
        {
          throw;
        }
    }
  }
  throw new MaximumRetryAttemptedException($"Maximum retry attempts {retryCount}, has be attempted.");
}

[Serializable]
public class MaximumRetryAttemptedException : Exception
{
  public MaximumRetryAttemptedException(string message) : base(message) { }
}

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

Blockieren ist die extremste Form der Drosselung. Wir blockieren selten einen Mandanten, es sei denn, wir erkennen langfristig übermäßigen Datenverkehr, der den allgemeinen Zustand der SharePoint-Onlinedienste gefährden kann. Wir wenden Blöcke an, um zu verhindern, dass übermäßiger Datenverkehr die Leistung und Zuverlässigkeit von SharePoint Online beeinträchtigt. Ein Block, der auf App- oder Benutzerebene platziert wird, verhindert, dass der problematische Prozess ausgeführt wird, bis Sie das Problem behoben haben. Wenn wir Ihr Abonnement blockieren, müssen Sie Maßnahmen ergreifen, um die problematischen Prozesse zu ändern, bevor die Blockierung entfernt werden kann.

Wenn wir Ihr Abonnement blockieren, werden Sie im Office 365 Message Center über den Block informiert. Die Nachricht beschreibt, was den Block verursacht hat, enthält Anleitungen zur Behebung des Problems und gibt an, an wen Sie sich wenden müssen, um den Block zu entfernen.

Siehe auch