Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce document explique les limites de SharePoint Embedded pendant la préversion publique.
Remarque
Il s’agit de limites d’aperçu susceptibles d’être modifiées.
Limites de taille
Le tableau suivant définit les limites de taille des conteneurs »
| Resource | Limite |
|---|---|
| Types de conteneurs qu’un locataire partenaire peut créer | 5* |
| Types de conteneurs qu’une application peut posséder | 1 |
| Conteneurs d’un type de conteneur par locataire consommateur | 100 000* |
| Stockage par type de conteneur par locataire consommateur | 100 To* |
| Fichiers et dossiers par conteneur | 30M |
| Stockage par conteneur | 25 To |
| Fichiers et dossiers avec des autorisations additives par conteneur | 5k |
| La taille des fichiers | 250 Go |
| Nombre de versions par fichier | 500 (Paramètre par défaut des limites automatiques de l’historique des versions) |
| Nombre d’utilisateurs partagés par dossier ou fichier | 5k |
Remarque
La limite peut être augmentée par demande.
Limitation
Modèles et bonnes pratiques
Lorsque les applications atteignent les limites du service, vous recevez un code de status HTTP 429 (« Trop de requêtes »). Vous pouvez également recevoir un code http status 503 (« Serveur trop occupé »).
En général, les meilleures pratiques pour gérer la limitation sont les suivantes :
- Réduisez le nombre de demandes simultanées.
- Évitez les pics de requête.
- Respectez l’en-tête
Retry-AfterHTTP.
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 sont comptabilisées dans les limites d’utilisation, de sorte que l’échec de l’exécution Retry-After peut entraîner une limitation plus élevée.
Limites de débit d’API
SharePoint Embedded fournit diverses API. Différentes API ont des coûts différents en fonction de la fonctionnalité et de la complexité de l’API. Le coût des API est normalisé et exprimé par unités de ressources. Les limites de débit d’API sont également définies à l’aide d’unités de ressources.
| Unités de ressources par demande | Opérations |
|---|---|
| 1 | Requête d’élément unique, telle que l’obtention d’un élément |
| 2 | Requête à plusieurs éléments, telle que créer, mettre à jour, supprimer et charger des enfants de liste |
| 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.
Le tableau suivant répertorie les limites de débit d’API pour les applications et les conteneurs.
| Resource | Limites |
|---|---|
| Demandes par conteneur | 3 000 unités de ressources par min |
| Demandes par application et par locataire | 12 000 unités de ressources par min* |
| Demandes par utilisateur | 600 unités de ressources par min |
Remarque
* La limite peut être augmentée par demande.
Les limites d’application sont définies en unités de ressources, et le taux de demandes réel, par exemple les demandes par minute, varie en fonction de l’API choisie et de son coût d’unité de ressource correspondant. En règle générale, vous pouvez estimer le taux de demandes en moyenne environ deux unités de ressources par demande et en divisant les limites d’unités de ressources d’application par 2. La réduction de l’utilisation des opérations d’autorisation peut considérablement améliorer le taux d’appel, car ces opérations ont l’impact le plus significatif sur la consommation globale des ressources.