Comprendre les limites et les modèles d’appel

S’applique à : Développeur

Utilisez cet article pour planifier les modèles d’appel SharePoint Embedded avant de générer des opérations de contenu et de conteneur volumineuses. SharePoint Embedded exprime le débit en unités de ressources par minute (un modèle de coût de requête normalisé) plutôt qu’en taux fixe de requêtes par seconde ; la section Limites de débit d’API explique comment convertir les unités de ressources en un taux de demande attendu.

Les limites marquées par * peuvent être augmentées sur demande via le support Microsoft ou votre contact d’intégration SharePoint Embedded ; planifiez la limite par défaut et demandez une augmentation avant de l’approcher en production.

Limiter les catégories

Les limites SharePoint Embedded affectent :

  • Nombre de types de conteneur*
  • Nombre de conteneurs*
  • Stockage par type de conteneur et conteneur
  • Fichiers et dossiers
  • Autorisations
  • La taille des fichiers
  • Nombre de versions
  • Limites de débit d’API*
  • Demandes par application, conteneur et utilisateur*

Remarque

Ces limites peuvent changer. Vérifiez les limites actuelles avant de lancer en production.

Limites de taille

SharePoint Embedded applique les limites de taille suivantes.

Resource Limite
Types de conteneurs qu’un client de développement peut créer 25*
Types de conteneurs dont une application peut être propriétaire 1
Stockage par type de conteneur par locataire consommateur 100 To*
Files et dossiers par conteneur 30 millions
Stockage par conteneur 25 To
Files et dossiers avec des autorisations supplémentaires par conteneur 5,000
La taille des fichiers 250 Go
Nombre de versions par fichier 500 (limite de l’historique des versions automatique par défaut)
Nombre d’utilisateurs partagés par dossier ou fichier 5,000
Colonnes personnalisées par conteneur 40

Un astérisque (*) indique une limite dont vous pouvez demander l’augmentation.

Parmi les types de conteneurs créés par un client, l’un peut être un type de conteneur d’essai gratuit pour le développement et le test, et les autres sont des types de conteneurs standard (facturés). Les nouveaux clients démarrent avec une valeur par défaut inférieure qui peut être levée sur demande. Pour plus d’informations sur la version d’évaluation par rapport à la version standard, consultez Créer et configurer un type de conteneur.

Conception pour les limites de type de conteneur

Une application peut posséder un type de conteneur.

Ne modélisez pas chaque client, projet, espace de travail ou utilisateur comme un type de conteneur distinct.

Utilisez des conteneurs pour les instances de stockage d’application dans le type de conteneur.

Choisissez un type de conteneur pour le comportement au niveau de l’application, la relation d’accès et la responsabilité de facturation.

Pour la planification du type de conteneur, consultez Comprendre les types de conteneurs et les conteneurs.

Conception pour les limites de conteneur

Les conteneurs fournissent la limite de stockage et de sécurité.

Planifiez le nombre de conteneurs que chaque locataire consommateur peut créer.

Tenez compte des conteneurs actifs et de tout cycle de vie de conteneur supprimé susceptible d’affecter les quotas ou le stockage.

Alignez les limites du conteneur sur les exigences d’accès, de cycle de vie et de gouvernance.

Conception pour les limites d’autorisations

SharePoint Embedded autorise jusqu’à 5 000 fichiers et dossiers avec des autorisations supplémentaires par conteneur.

Évitez de concevoir chaque fichier ou dossier de manière à ce qu’il dispose d’autorisations uniques lorsqu’un modèle au niveau du conteneur ou du dossier est suffisant.

Utilisez l’appartenance et les rôles de conteneur dans la mesure du possible.

Pour connaître les concepts d’autorisation, consultez Planifier l’authentification et les autorisations.

Réponses limitées

Lorsque les applications atteignent les limites de service, SharePoint Embedded peut renvoyer :

  • HTTP 429 Too Many Requests.
  • HTTP 503 Server Too Busy.

Les deux réponses incluent un Retry-After en-tête.

L’en-tête indique à l’application combien de temps attendre avant de réessayer ou d’effectuer une nouvelle demande.

Importante

Les requêtes limitées sont comptabilisées dans les limites d’utilisation. Si vous ignorez Retry-After, votre application peut entraîner d’autres limitations.

Conseils relatifs aux nouvelles tentatives

Implémentez une logique de nouvelle tentative qui :

  • Détecte les protocoles HTTP 429 et 503.
  • Lit l’en-tête Retry-After .
  • Attend la durée spécifiée avant de réessayer.
  • Réduit l’accès concurrentiel après la limitation.
  • Évite les boucles de nouvelle tentative immédiates.
  • Évite les pics de demandes après une période d’attente.

Utilisez de nouvelles tentatives limitées et des échecs persistants de surface dans la télémétrie des opérations. Pour obtenir des instructions générales sur la gestion des réponses de limitation, consultez les instructions de limitation de Microsoft Graph.

Conseils sur l’accès concurrentiel

Réduisez le nombre de demandes simultanées lorsque la limitation de requêtes se produit.

Évitez les modèles en rafale qui envoient de nombreuses demandes en même temps.

Répartissez le travail dans le temps lors du traitement de grands ensembles de conteneurs ou de fichiers.

Utilisez des files d’attente ou des travailleurs en arrière-plan pour fluidifier le trafic.

Donnez la priorité aux opérations visibles par l’utilisateur plutôt qu’à la maintenance en arrière-plan lorsque les limites sont proches.

Unités de ressources d’API

Les différentes API ont des coûts différents en fonction de leur fonctionnalité et de leur complexité.

Le coût est normalisé et exprimé en unités de ressources.

Les limites de débit d’API sont également définies à l’aide d’unités de ressources.

Chaque demande calcule le coût des unités de ressources en fonction de sa complexité :

Unités de ressources par demande Opérations
1 Requête d’élément unique, telle que obtenir un élément.
2 Requête multi-éléments, tels que la liste des enfants, la création, la mise à jour, la suppression et le chargement.
5 Toutes les opérations de ressource d’autorisation, y compris $expand=permissions.

Remarque

Les coûts unitaires des ressources peuvent changer.

Limites de débit de l’API

SharePoint Embedded applique ces limites de débit d’API.

Resource Limite
Requêtes par conteneur 3 000 unités de ressources par minute
Demandes par application par locataire 12 000 unités de ressources par minute*
Requêtes par utilisateur 600 unités de ressources par minute

Un astérisque (*) indique une limite dont vous pouvez demander l’augmentation.

Les limites d’application sont définies en unités de ressources.

Le nombre réel de requêtes par minute dépend des API que vous appelez et de leur coût unitaire de ressources.

Pour estimer le taux de demandes, faites la moyenne d’environ deux unités de ressources par demande et divisez la limite d’unités de ressources d’application par deux.

Limitation du taux de création de conteneurs

Par client consommateur et pendant les heures de pointe du client, la création de conteneurs est limitée à 5 nouveaux conteneurs par seconde. Les demandes au-delà de cette limite sont limitées en débit. En dehors des heures de pointe, les conteneurs peuvent être créés plus rapidement.

Coûts d’opération d’autorisation

Les opérations de ressources d’autorisation ont un coût unitaire de ressource plus élevé.

Les opérations qui comprennent $expand=permissions sont répertoriées dans cinq unités de ressources.

Réduisez l’extension inutile des autorisations.

Appliquer les décisions dérivées des autorisations de cache uniquement lorsqu’elles sont sûres pour votre modèle de sécurité.

Actualiser les données d’autorisation lorsque des modifications d’appartenance ou de rôle se produisent.

Considérations relatives au traitement par lot

Le traitement par lot peut réduire la surcharge du client, mais il ne supprime pas les limites de service ou l’impact sur la facturation.

Comptez chaque opération sous-jacente lorsque vous estimez la consommation unitaire de ressources et le coût de transaction.

Évitez de créer des lots qui concentrent trop de travail sur un conteneur, une application, un locataire ou un utilisateur dans un court intervalle.

Respectez les réponses de limitation pour les opérations par lots en fonction des détails de réponse renvoyés par la plateforme.

Considérations liées aux performances

Concevoir pour :

  • Moins d’appels demandant beaucoup d’autorisations.
  • Concurrence prévisible.
  • Synchronisation incrémentielle.
  • Reculer après l’accélération.
  • Séparation du travail de premier plan et d’arrière-plan.
  • Équité au niveau du locataire pour les applications mutualisées.
  • Surveillance du taux de demande, des codes de réponse et de la latence.

Pour connaître l’impact des transactions d’API sur la facturation, consultez Choisir un modèle de facturation.

Suivi opérationnel

Piste :

  • HTTP 429 et 503 taux de réponse.
  • Nombre de nouvelles tentatives et durées d’attente.
  • Opérations gourmandes en ressources.
  • Requêtes par application, client, utilisateur et conteneur.
  • Arrière-plan Longueur de la file d’attente des travaux.
  • Croissance du stockage par conteneur et locataire.
  • Fréquence d’opération d’autorisation.

Utilisez ces signaux pour ajuster l’accès concurrentiel et identifier les locataires ou les flux de travail qui nécessitent des modifications de conception.

Liste de vérification de planification

  • Confirmez les limites de taille actuelles avant le lancement de la production.
  • Modélisez des conteneurs plutôt que d’en créer de nombreux.
  • Estimez le stockage par conteneur et par locataire consommateur.
  • Estimez le nombre de fichiers et de dossiers.
  • Évitez les autorisations supplémentaires inutiles.
  • Implémenter Retry-After la gestion pour 429 et 503.
  • Limitez l’accès concurrentiel et évitez les pics.
  • Estimez l’utilisation des unités de ressources par type d’opération.
  • Réduisez les opérations demandant beaucoup d’autorisations.
  • Surveillez la limitation et la latence.
  • Incluez l’impact de la facturation dans la conception de l’API.

Étapes suivantes

Commencer à créer avec le démarrage rapide : Créez votre première application avec VS Code.

  • Last updated on