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

  • Article
  • 16 minutes de lecture

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 à mettre à jour d'optimiser les performances et la fiabilité du service SharePoint Online. La limitation 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 demandes qu’une application effectue, y compris les appels Microsoft Graph, CSOM ou REST, SharePoint Online renvoie le code d’état HTTP 429 (« Trop de demandes ») ou 503 (« Serveur trop occupé ») et les demandes échouent.

  • 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 rencontre des pics de charge temporaires alors attendus.

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 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, compte pour 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 4,800,000 6,000,000

Notes

Nous nous réservons le droit de modifier les limites des unités de ressources.

En termes de coûts d’API, les API Microsoft Graph ont un coût unitaire de ressource 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
    		•
    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
    		•

    Notes

    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, et 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 unitaire de ressource prédéterminé et 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 plus importante que les limites décrites dans ce document. Nous vous recommandons vivement de choisir les API Microsoft Graph sur les API CSOM et REST lorsque cela est possible.

    Étant donné que les limites d’application sont en unités de ressources, le taux de demandes réel, par exemple les demandes par minute, dépend du choix de l’API de l’application et du coût unitaire de ressource d’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 propres limites au sein d’un locataire et que nous autorisons les locataires à exécuter plusieurs applications, 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 demandes à 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
    • Choisissez les API Microsoft Graph sur les API CSOM et REST lorsque cela est 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 est une API née dans le cloud qui dispose des dernières améliorations et optimisations. En général, Microsoft Graph consomme moins de ressources que CSOM et REST pour obtenir les mêmes fonctionnalités. Par conséquent, l’adoption de Microsoft Graph peut améliorer les performances de l’application et réduire la limitation.

    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 comptabilisées 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 demandes 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 du 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é.

    Notes

    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 ressource de 1 minute de l’application Utilisation >= 80 % de la limite Unité de ressources Lorsqu’une application consomme 80 % ou plus de sa limite d'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

    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 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 ?

    • If you've created an application, the recommendation is to register and use AppID and AppTitle – This will ensure the best overall experience and best path for any future issue resolution. Include also the User Agent string information as defined in following step.

      Notes

      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 de nom suivantes

    Type Agent utilisateur Description
    Application ISV ISV|CompanyName|AppName/Version S’identifier en tant que ISV 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
    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 demande http et potentiellement inscrire votre application web également en tant qu’application, où approprié.

    Notes

    Le format de la chaîne de l’agent utilisateur doit suivre RFC2616, veuillez donc suivre les recommandations ci-dessus pour les bons séparateurs. Il suffit également d’ajouter la chaîne de l’agent utilisateur existant 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, fournisseurs de sauvegarde, index de recherche, moteurs de classification, outils de protection contre la perte de données, ainsi que les autres qui tentent de gérer les données et d’y appliquer les modifications.

    • Trafic fastidieuse

      Un seul processus dépasse considérablement les limites de limitation, en permanence, pendant une période de temps.

      • You used web services to build a tool to synchronize user profile properties. The tool updates user profile properties based on information from your line-of-business (LOB) human resources (HR) system. The tool makes calls at too high a frequency.
      • You're running a load-testing script on SharePoint Online and you get throttled. Load testing isn't allowed on SharePoint Online.
      • You customized your team site on SharePoint Online, for example, by adding a status indicator on the Home page. This status indicator updates frequently, which causes the page to make too many calls to the SharePoint Online service - this triggered throttling.
      • 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

      Unsupported use of SharePoint Online may experience throttling. Using SharePoint and OneDrive as an intermediary service between Microsoft 365 and another repository is an example of an unsupported use case.

    • 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 du client. 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. Lorsque cela ne peut pas être évité, chaque instance de code personnalisé qui interagit avec SharePoint Online doit être conçue pour tenir compte de la limitation présente.

    Limites spécifiques au scénario

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

    Lorsque vous utilisez des API de recherche SharePoint Online avec l’authentification d’application uniquement et que l’application dispose de l’autorisation Sites.Read.All (ou 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 ODB privé 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 des résultats de recherche de personnes

    Lors de la recherche à l’aide d’une source de résultats qui demande des résultats de personnes, nous pouvons limiter toutes les demandes dépassant une limite de 25 demandes par seconde. Cette limite s’applique conjointement à toutes les demandes utilisant la source prête à l’emploi de résultats « Résultats des personnes locales » et à toutes les demandes utilisant des sources de résultats de recherche de personnes personnalisées.

    Si vous avez des applications ou des composants qui provoquent la limitation des demandes 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 demandes 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 demandes 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.

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

    Blocking is the most extreme form of throttling. We rarely ever block a tenant, unless we detect long-term, excessive traffic that may threaten the overall health of the SharePoint Online service. We apply blocks to prevent excessive traffic from degrading the performance and reliability of SharePoint Online. A block - which is placed at the app or user level - prevents the offending process from running until you fix the problem. If we block your subscription, you must take action to modify the offending processes before the block can be removed.

    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