Partager via

Éviter d’être limité ou bloqué dans SharePoint Online

  • Article

Découvrez la limitation dans SharePoint Online et découvrez comment éviter d’être limité ou bloqué.

Est présent familier ? Vous exécutez une application ( par exemple, pour analyser des fichiers dans SharePoint Online), mais vous êtes limité. Ou pire encore, vous êtes bloqué. Que se passe-t-il et quelles sont les possibilités pour faciliter l'arrêter ?

Qu’est-ce que la limitation ?

SharePoint Online utilise la limitation des tentatives d’accès pour maintenir les performances et la fiabilité du service SharePoint Online. La limitation des tentatives d’accès limite le nombre d’appels ou d’opérations d’API dans une fenêtre de temps pour empêcher la surutilisation des ressources.

Que se passe-t-il lorsque vous obtenez limitées dans SharePoint Online ?

Lorsque les limites d’utilisation sont dépassées, SharePoint Online limite les demandes supplémentaires de ce client pendant une courte période.

Pour les demandes effectuées par un utilisateur directement dans le navigateur, SharePoint Online vous redirige vers la page d’informations sur les limitations et les demandes échouent.

Pour les requêtes effectuées par une application, y compris les appels Microsoft Graph, CSOM ou REST, SharePoint Online retourne le code d’état HTTP 429 (« Trop de requêtes ») ou 503 (« Serveur trop occupé ») et les requêtes échoueront.

  • HTTP 429 indique que l’application appelante a envoyé trop de demandes dans une fenêtre de temps et a dépassé une limite prédéterminée.
  • HTTP 503 indique que le service n’est pas prêt à gérer la demande. La cause courante est que le service subit des pics de charge temporaires plus importants que prévu.

Dans les deux cas, un en-tête Retry-After est inclus dans la réponse indiquant la durée pendant laquelle l’application appelante doit attendre avant de réessayer ou d’effectuer une nouvelle demande. Les demandes limitées étant comptabilisées dans les limites d’utilisation, le fait de ne pas respecter Retry-After peut entraîner davantage de limitation.

Si l’application incriminée continue de dépasser les limites d’utilisation, SharePoint Online peut bloquer complètement l’application ou des modèles de demande spécifiques de l’application ; Dans ce cas, l’application continue d’obtenir le code d’état HTTP 503 et Microsoft informe le locataire du bloc dans l’Centre de messages Office 365.

Limitation d'utilisateurs

La limitation des tentatives d’accès limite le nombre d’appels et d’opérations collectivement effectués par les applications pour le compte d’un utilisateur afin d’éviter la surutilisation des ressources.

Cela dit, il est rare qu’un utilisateur soit limité dans SharePoint Online. Le service est robuste et il est conçu pour gérer un volume élevé. Si vous êtes limité, 99 % du temps, cela est dû à du code personnalisé, tel que des composants WebPart personnalisés, un affichage de liste complexe et des requêtes, ou des applications personnalisées exécutées par les utilisateurs. Cela ne signifie pas qu'il n'existe pas d'autres moyens de se faire étrangler, mais qu'ils sont moins courants. Par exemple, un utilisateur synchronisant une grande quantité de données sur 10 ordinateurs en même temps peut déclencher une limitation.

Limitation de l’application

Outre la limitation par compte d’utilisateur, des limites sont également appliquées aux applications dans un locataire.

Chaque application a ses propres limites dans un locataire, qui sont basées sur le nombre de licences achetées par organisation (voir les plans répertoriés dans les limites SharePoint pour les licences incluses). Chaque requête effectuée par une application sur tous les points de terminaison d’API, y compris Microsoft Graph, CSOM et REST, est prise en compte dans l’utilisation de l’application.

SharePoint fournit différentes API. Différentes API ont des coûts différents en fonction de la complexité de l’API. Le coût des API est normalisé par SharePoint et exprimé par unités de ressources. Les limites de l’application sont également définies à l’aide d’unités de ressources.

Le tableau ci-dessous définit les limites d’unités de ressources pour une application dans un locataire :

Nombre de licences 0 1 000 – 1 000 – 000 5k - 15 000 15 000 - 50 000 Plus de 50 000
Application 1 minute 1 200 2400  3 600 4 800 6 000
Application quotidienne 1 200 000 2 400 000 3 600 000 4800000 6 000 000

Remarque

Microsoft se réserve le droit de modifier les limites des unités de ressources.

Pour les applications multilocataires :

  1. Chaque locataire hébergeant l’application est considéré comme distinct, fonctionnant indépendamment des autres. Par conséquent, chaque application est soumise à ses propres limites d’utilisation au sein de chaque locataire, comme défini ci-dessus.
  2. La consommation d’unités de ressources par l’application doit être mesurée par locataire et par application. Cela garantit que chaque paire locataire-application reste dans les limites de ressources autorisées spécifiées pour ce locataire particulier.
  3. Si l’application atteint sa limite de ressources au sein d’un locataire, cette occurrence n’affectera pas les autres instances de l’application fonctionnant dans différents locataires. L’utilisation des ressources de chaque locataire est isolée, ce qui empêche tout impact sur les autres locataires.

En termes de coûts d’API, les API Microsoft Graph ont un coût d’unité de ressources prédéterminé par requête :

Unités de ressources par demande Opérations
1
  • Requête d’élément unique, telle que l’obtention d’un élément
  • Delta avec un jeton
  • Télécharger le fichier à partir de l’élément de lecteur
    		•
    2
  • Requête multi-élément, telle que les enfants de liste, à l’exception de delta avec un jeton
  • Créer, mettre à jour, supprimer et charger
    		•
    5
  • Toutes les opérations de ressource d’autorisation, y compris $expand=autorisations
    		•

    Remarque

    Nous nous réservons le droit de modifier le coût unitaire de la ressource API.

    Delta avec un jeton est le moyen le plus efficace d’analyser du contenu dans SharePoint. Nous abordons plus en détail les meilleures pratiques d’analyse des applications. Pour aider les applications qui suivent les instructions, nous réduisons le coût de l’unité de ressources des demandes delta avec un jeton à 1 unité de ressources, bien qu’il s’agisse d’une requête à plusieurs éléments. La requête delta sans jeton est considérée comme une requête multi-élément et coûte 2 unités de ressources par demande.

    Dans le traitement par lots, les demandes d’un lot sont évaluées individuellement par unités de ressources.

    CSOM et REST n’ont pas de coût d’unité de ressources prédéterminé. De plus, ils consomment généralement plus d’unités de ressources que les API Microsoft Graph pour obtenir la même fonctionnalité. En plus des limites d’unités de ressources, CSOM et REST sont également soumis à d’autres limites de ressources internes. Par conséquent, si les applications appellent CSOM et REST, elles peuvent subir une limitation des tentatives d’accès plus importante que les limites décrites dans ce document. Nous vous recommandons vivement de choisir les API Microsoft Graph par rapport aux API CSOM et REST dans la mesure du possible.

    Étant donné que les limites d’application sont en unités de ressources, le taux de requêtes réel, par exemple les requêtes par minute, dépend du choix de l’API de l’application et du coût d’unité de ressources API correspondant. En général, vous pouvez estimer le taux de demandes à l’aide d’une moyenne de 2 unités de ressources par demande et diviser les limites d’unités de ressources par 2 pour obtenir le taux de demande estimé.

    Bien que chaque application ait ses limites au sein d’un locataire et que nous autorisions les locataires à exécuter plus d’une application, plusieurs applications exécutées sur le même locataire partagent le même compartiment de ressources et, dans de rares cas, peuvent entraîner une limitation du débit lorsque trop d’applications envoient des requêtes à ce moment-là.

    Comment gérer la limitation ?

    Voici un résumé rapide des meilleures pratiques pour gérer la limitation :

    • Réduire le nombre de demandes simultanées
    • Éviter les pics de demande
    • Choisir les API Microsoft Graph sur les API CSOM et REST dans la mesure du possible
    • Utilisez les en-têtes HTTP Retry-After et RateLimit
    • Définir votre trafic afin que nous sachions qui vous êtes (voir la section sur les meilleures pratiques de définition du trafic ci-dessous)

    Comme indiqué précédemment, Microsoft Graph repose sur des API cloud qui bénéficient des dernières améliorations et optimisations. En général, Microsoft Graph consomme moins de ressources que CSOM et REST pour atteindre la même fonctionnalité. L’adoption de Microsoft Graph peut par conséquent améliorer les performances de l’application et réduire la limitation des tentatives d’accès.

    Si vous rencontrez une limitation, nous avons besoin de l’en-tête HTTP Retry-After pour garantir un délai minimal jusqu’à ce que la limitation soit supprimée. Le RateLimit des en-têtes HTTP vous envoient des signaux précoces lorsque vous êtes proche des limites et que vous pouvez réduire de manière proactive les demandes pour éviter d’atteindre la limitation.

    En-tête Retry-after

    Lorsque les applications rencontrent une limitation, SharePoint Online retourne un en-tête HTTP Retry-After dans la requête indiquant la durée en secondes pendant laquelle l’application appelante doit attendre avant de réessayer ou d’effectuer une nouvelle demande.

    Le respect de la Retry-After en-tête HTTP est le moyen le plus rapide de gérer les limitations, car SharePoint Online détermine dynamiquement le bon moment pour réessayer.

    Les demandes limitées étant comptabilisées dans les limites d’utilisation, le fait de ne pas respecter Retry-After peut entraîner davantage de limitation. En d’autres termes, les nouvelles tentatives agressives s’appliquent aux applications appelantes, car même si les appels échouent, elles sont toujours prises en compte dans les limites d’utilisation. Le respect de l’en-tête HTTP Retry-After garantit le délai le plus court et réduit les quotas de perte dans les requêtes limitées.

    En-têtes RateLimit - préversion

    En plus de l’en-tête Retry-After dans la réponse aux requêtes limitées, SharePoint Online retourne également les en-têtes RateLimit IETF pour les limites sélectionnées dans certaines conditions afin d’aider les applications à gérer la limitation de débit. Nous recommandons aux applications de tirer parti de ces en-têtes pour éviter d’atteindre la limitation.

    • RateLimit-Limit contient la limite dans la fenêtre de temps actuelle.
    • RateLimit-Remaining indique le quota restant dans la fenêtre active.
    • RateLimit-Reset indique le nombre de secondes jusqu’à ce que le quota soit réapprovisionné.

    Remarque

    Ces en-têtes sont actuellement en version bêta et peuvent être modifiés. Au moment de l’adoption des en-têtes, la spécification IETF était en brouillon. L’implémentation actuelle est basée sur le brouillon-03 de la spécification IETF. Il est possible que des modifications soient apportées lorsque la spécification est finale, et nous nous adapterons à ces modifications à l’avenir.

    Les en-têtes RateLimit sont retournés sur la base des meilleurs efforts, de sorte que les applications peuvent ne pas recevoir les en-têtes dans toutes les conditions. En outre, il existe d’autres limites qui ne sont pas présentées dans les en-têtes RateLimit , de sorte que les applications peuvent être limitées même avant d’atteindre la limite décrite dans les en-têtes RateLimit . Voici la liste des limites pour lesquelles nous prenons en charge les en-têtes RateLimit. Les stratégies et les valeurs sont susceptibles d’être modifiées :

    limit Condition valeur limite Description
    Unité de ressources de 1 minute d’application Utilisation >= 80 % de la limite Unité de ressources Lorsqu’une application consomme 80 % ou plus de sa limite de 1 minute d’application, la limite, les éléments restants et la réinitialisation sont retournés.

    Voici quelques exemples pour vous aider à comprendre les en-têtes RateLimit :

    • Une application a consommé 90 % de son quota d’unités de ressources (1 080 sur 1 200) et sa consommation est comprise dans toutes les limites qui s’y appliquent. La demande réussit et les en-têtes RateLimit sont retournés.
    HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5
    • Une application a consommé 100 % de son quota d’unités de ressources. Elle est donc limitée en raison de cette stratégie. La demande est limitée et les en-têtes RateLimit sont retournés. Le Retry-After correspond au RateLimit-Reset.
    HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31
    • Une application a consommé 90 % de son quota d’unités de ressources, mais sa consommation a déjà atteint d’autres limites que les en-têtes RateLimit ne prennent pas en charge. Dans ce cas, la requête est limitée et les en-têtes RateLimit ne sont pas renvoyés pour éviter toute confusion, bien que la condition de retour des en-têtes soit remplie.
    HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Pour plus d’informations, consultez Empêcher la limitation des tentatives d’accès dans votre application à l’aide des en-têtes RateLimit dans SharePoint Online

    Comment décorer votre trafic HTTP ?

    Le trafic correctement décoré sera prioritaire sur le trafic qui n’est pas correctement décoré.

    Quelle est la définition du trafic non corrigé ?

    • Le trafic n’est pas corrigé s’il n’existe aucune chaîne AppID/AppTitle et User Agent dans les appels d’API à SharePoint Online. La chaîne de l’agent utilisateur doit être dans un format spécifique comme décrit ci-dessous.
    • Si vous développez une application web qui s’exécute dans le navigateur, la plupart des navigateurs modernes n’autorisent pas le remplacement de la chaîne de l’Agent utilisateur et vous n’avez pas besoin de l’implémenter.

    Quelles sont les recommandations ?

    • Si vous avez créé une application, la recommandation est de vous inscrire et utiliser AppID et AppTitle. Cette option garantit la meilleure expérience globale et le meilleur parcours pour toute résolution de problème futurs. Incluez également les informations de chaîne de l’agent utilisateur définie dans l’étape suivante.

      Remarque

      Référez-vous à la Documentation sur l’identité de Microsoft, telle que la page Démarrage rapide : Inscrire une application avec la plateforme d’identités Microsoft pour obtenir des informations sur la création d’une application Azure AD.

    • Veillez à inclure la chaîne de l’agent utilisateur dans votre appel d’API pour SharePoint avec les conventions d’affectation de noms suivantes

    Type Agent utilisateur Description
    Application ISV ISV|CompanyName|AppName/Version Identifiez-vous en tant qu’éditeur de logiciels indépendant et incluez le nom de la société, nom de l’application séparées par un caractère barre verticale, puis ajoutez le numéro de version séparé par un caractère barre oblique
    Application d’entreprise NONISV|CompanyName|AppName/Version S’identifier en tant que NONISV et inclure le nom de la société, nom de l’application séparées par un caractère de canal, puis ajoutez le numéro de version séparé par un caractère barre oblique
    • Si vous créez vos propres bibliothèques JavaScript associées, qui sont utilisées pour appeler des API SharePoint Online, assurez-vous d’inclure les informations de l’agent utilisateur à votre requête HTTP et potentiellement inscrire votre application web également en tant qu’application, le cas échéant.

    Remarque

    Le format de la chaîne de l’agent utilisateur doit suivre RFC2616, suivez donc les recommandations ci-dessus pour les séparateurs appropriés. Vous pouvez également ajouter la chaîne de l’agent utilisateur existante aux informations demandées.

    Scénarios de limitation courants dans SharePoint Online

    Les causes les plus courantes de limitation dans SharePoint Online par l'utilisateur sont le modèle objet côté client (CSOM) ou Representational State Transfer (REST) du code qui effectue des actions trop trop souvent.

    • Trafic occasionnel

      Une charge constante ou des requêtes complexes répétitives sur SharePoint Online doivent être optimisés pour un faible impact. Ne pas suivre les meilleures pratiques pour obtenir la numérisation des applications qui traitent des fichiers en bloc est susceptible de provoquer une limitation. Ces applications incluent les moteurs de synchronisation, les fournisseurs de sauvegarde, les indexeurs de recherche, les moteurs de classification, les outils de protection contre la perte de données, ainsi que les autres qui tentent de raisonner sur l’ensemble des données et d’y appliquer des modifications.

    • Trafic fastidieuse

      Un seul processus dépasse considérablement les limites de limitation des tentatives d’accès, en permanence, pendant une période de temps.

      • Services web vous permet de créer un outil pour synchroniser les propriétés de profil utilisateur. L'outil met à jour les propriétés de profil utilisateur en fonction des informations à partir de votre système de ressources humaines (RH) de métier (LOB). L'outil effectue des appels à une fréquence de trop élevée.
      • Vous exécutez un script de test de charge sur SharePoint Online et vous êtes limité. Le test de charge n’est pas autorisé sur SharePoint Online.
      • Vous avez personnalisé votre site d'équipe sur SharePoint Online, par exemple, en ajoutant un indicateur d'état de la page d'accueil. Cet indicateur d'état des mises à jour fréquemment, qui provoque la page à rendre trop grand nombre d'appels au service SharePoint Online - cela déclenchée limitation.
      • L'exécution du client OneDrive synchronisation en même temps que des applications de migration ou des applications qui explorent des sites et réécrivent des données peut entraîner des volumes de demandes élevés susceptibles de déclencher un étranglement.

    • Cas d’utilisation non pris en charge

      L’utilisation non prise en charge de SharePoint Online peut subir une limitation. L’utilisation de SharePoint et OneDrive comme service intermédiaire entre Microsoft 365 et un autre référentiel est un exemple de cas d’utilisation non pris en charge.

    • La création de plusieurs ID d’application pour la même application

      Ne créez pas d’AppID distincts où les applications effectuent essentiellement les mêmes opérations, telles que la sauvegarde ou la protection contre la perte de données. Les applications qui s’exécutent sur le même locataire partagent finalement la même ressource que le locataire. Historiquement, certaines applications ont essayé cette approche pour contourner la limitation des applications, mais ont fini par épuiser la ressource du client et provoquer la limitation de plusieurs applications dans le client.

    Limites spécifiques au scénario

    Lors de l’authentification dans l’application uniquement avec l’autorisation Sites.Read.All

    Lorsque vous utilisez les API de recherche SharePoint Online avec une authentification par application uniquement et que l’application dispose de l’autorisation Sites.Read.All (ou d’une autorisation plus forte), l’application est inscrite avec des autorisations complètes et est autorisée à interroger tout votre contenu SharePoint Online (y compris le contenu privé OneDrive Entreprise de l’utilisateur).

    Pour garantir que le service reste rapide et fiable, les requêtes utilisant cette autorisation sont limitées à 25 requêtes par seconde. La requête de recherche retourne une réponse HTTP 429. Lorsque vous attendez la récupération de limitation, veillez à suspendre toutes les demandes de requête de recherche que vous pouvez effectuer au service à l’aide d’autorisations d’application uniquement similaires. L’exécution d’appels supplémentaires lors de la réception de réponses de limitation étend le temps nécessaire à l’annulation de la limitation de votre application.

    Lors de la recherche à l’aide d’autorisations d’utilisateur déléguées

    La recherche avec des autorisations d’utilisateur déléguées se produit lorsqu’une application envoie une requête de recherche avec les autorisations de l’utilisateur connecté. Voici quelques exemples de requêtes déléguées : la zone de recherche d’une page SharePoint, un composant WebPart basé sur la recherche ou une application personnalisée incorporée dans une page SharePoint, et une requête de flux de travail Power Automate pour obtenir des informations sur les éléments.

    Pour garantir la stabilité du service, le service limite les requêtes d’utilisateur déléguées qui dépassent 10 requêtes par seconde et par utilisateur. Cette limite par utilisateur regroupe toutes les requêtes provenant de toutes les applications. Si un seul utilisateur envoie plus de 10 requêtes de recherche par seconde, une requête HTTP 429 est retournée. L’application requérante doit attendre la durée du délai d’expiration spécifié dans l’en-tête de réponse avant d’envoyer des requêtes ultérieures. Lors de la conception d’applications basées sur la recherche, de pages SharePoint et de flux de travail, les responsables de l’implémentation doivent s’assurer que la page et l’application ne dépassent pas 10 requêtes par seconde au total et qu’elles gèrent 429 réponses de limitation des tentatives d’accès. Pour plus d’informations et de conseils sur la conception de page et l’optimisation de la recherche, consultez Optimiser les requêtes de recherche dans les pages de site modernes SharePoint Online et Utiliser l’outil Diagnostics de page pour SharePoint Online.

    Lors de la recherche des résultats de recherche de personnes

    Lors de la recherche à l’aide d’une origine des résultats qui demande des résultats d’utilisateurs, nous pouvons limiter toutes les requêtes dépassant une limite de 25 requêtes par seconde à l’échelle de l’organisation. Cette limite s’applique à toutes les requêtes CSOM et REST de recherche SharePoint à l’aide de l’origine des résultats « Résultats des utilisateurs locaux » prête à l’emploi ou d’une origine des résultats de recherche d’utilisateurs personnalisée.

    Si vous avez des applications ou des composants qui provoquent la limitation des requêtes de recherche de vos utilisateurs, nous vous recommandons d’effectuer les opérations suivantes :

    1. Déterminez si les demandes sont nécessaires pour votre application. Par exemple, si vous utilisez un site de recherche personnalisé, qui effectue de nombreuses requêtes simultanées, vérifiez si certaines de ces requêtes peuvent être supprimées sans impact significatif sur l’expérience de recherche de votre organisation. Vous pouvez également essayer notre expérience de recherche de personnes moderne dans Recherche Microsoft en effectuant une recherche à partir de la page de démarrage SharePoint. La recherche de personnes dans Recherche Microsoft a été optimisée pour de meilleures performances et des résultats plus pertinents.
    2. Évitez d’effectuer des demandes simultanées. Par exemple, au lieu d’émettre 10 requêtes en même temps, émettez-les consécutivement, la requête suivante uniquement après la fin de la requête précédente. Vous devrez peut-être mettre en cache ces résultats si vous en avez besoin rapidement, par exemple un chargement de page.
    3. Essayez de consolider les requêtes en une seule requête. Par exemple, au lieu de 10 requêtes simultanées pour WorkEmail:user1@constoso.com, WorkEmail:user2@constoso.com,..., WorkEmail:user10@contoso.com, essayez la requête unique, WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Envisagez d’utiliser l’API Microsoft Graph si un scénario à volume élevé de demandes (plus de 25 demandes par seconde) est vraiment nécessaire.

    Lors de l’accès aux sites OneDrive

    Lorsqu’un client effectue des tentatives excessives d’accès à de nombreuses collections de sites OneDrive qui n’existent pas, nous pouvons limiter les requêtes à partir de l’adresse IP de ce client. Le client reçoit une réponse HTTP 429 lors de l’accès à une collection de sites OneDrive pendant la période de limitation des tentatives d’accès.

    Que faire si vous êtes bloqué dans SharePoint Online ?

    Le blocage est la forme la plus extrême de limitation. Nous bloquons rarement un locataire, sauf si nous détectons un trafic à long terme excessif qui peut menacer l’état d’intégrité globale du service SharePoint Online. Un blocage est appliqué pour empêcher que ce trafic nuise aux performances et à la fiabilité de SharePoint Online. Un blocage placé au niveau du client ou de l’application, empêche le processus en cause d’être exécuté jusqu’à ce que vous corrigiez le problème. Si nous bloquons votre abonnement, vous devez intervenir et modifier les processus en cause pour que le blocage soit levé.

    Si nous bloquons votre abonnement, nous vous informerons du blocage dans l’Centre de messages Office 365. Le message décrit la cause de la limitation, fournit des instructions sur la façon de résoudre le problème et vous donne les coordonnées de la personne à contacter pour que la limitation soit levée.

    Voir aussi