Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este documento se explican los límites de SharePoint Embedded durante la versión preliminar pública.
Nota:
Estos son los límites de vista previa que están sujetos a cambios.
Límites de tamaño
En la tabla siguiente se definen los límites de tamaño de los contenedores"
| Recurso | Límite |
|---|---|
| Tipos de contenedor que un inquilino de asociado puede crear | 5* |
| Tipos de contenedor que una aplicación puede poseer | 1 |
| Contenedores de un tipo de contenedor por inquilino consumidor | 100 000* |
| Almacenamiento por tipo de contenedor por inquilino consumidor | 100 TB* |
| Archivos y carpetas por contenedor | 30 M |
| Almacenamiento por contenedor | 25 TB |
| Archivos y carpetas con permisos aditivos por contenedor | 5 000 |
| Tamaño de archivos | 250 GB |
| Recuento de versiones por archivo | 500 (Configuración predeterminada límites de historial de versiones automático) |
| Número de usuarios compartidos por carpeta o archivo | 5 000 |
Nota:
Se puede aumentar el límite por solicitud.
Limitación
Patrones y procedimientos recomendados
Cuando las aplicaciones alcanzan los límites del servicio, recibe un código de estado HTTP 429 ("Demasiadas solicitudes"). También puede recibir un código de estado HTTP 503 ("Servidor demasiado ocupado").
En general, los siguientes son los procedimientos recomendados para controlar la limitación:
- Reduzca el número de solicitudes simultáneas.
- Evite picos de solicitudes.
- Respetar el
Retry-Afterencabezado HTTP.
En ambos casos, se incluye un encabezado Retry-After en la respuesta que indica cuánto tiempo debe esperar la aplicación que realiza la llamada antes de volver a intentar o realizar una nueva solicitud. Las solicitudes limitadas cuentan para los límites de uso, por lo que el error de honor Retry-After podría dar lugar a una mayor limitación.
Límites de velocidad de API
SharePoint Embedded proporciona varias API. Las distintas API tienen costos diferentes en función de la funcionalidad y la complejidad de la API. El costo de las API se normaliza y expresa mediante unidades de recursos. Los límites de velocidad de API también se definen mediante unidades de recursos.
| Unidades de recursos por solicitud | Operaciones |
|---|---|
| 1 | Consulta de un solo elemento, como get item |
| 2 | Consulta de varios elementos, como enumerar elementos secundarios Crear, actualizar, eliminar y cargar |
| 5 | Todas las operaciones de recursos de permisos, incluida $expand=permissions |
Nota:
Nos reservamos el derecho de cambiar el costo de unidades de recursos de las API.
En la tabla siguiente se enumeran los límites de velocidad de API para aplicaciones y contenedores.
| Recurso | Límites |
|---|---|
| Solicitudes por contenedor | 3 000 unidades de recursos por minuto |
| Solicitudes por aplicación por inquilino | 12 000 unidades de recursos por minuto* |
| Solicitudes por usuario | 600 unidades de recursos por minuto |
Nota:
* Se puede aumentar el límite por solicitud.
Los límites de la aplicación se definen en unidades de recursos y la tasa real de solicitudes, como las solicitudes por minuto, varía en función de la API elegida y de su costo unitario de recursos correspondiente. Como regla general, puede calcular la tasa de solicitudes promediando aproximadamente dos unidades de recursos por solicitud y dividiendo los límites de unidades de recursos de aplicación en 2. La reducción del uso de las operaciones de permisos puede mejorar notablemente la tasa de llamadas, ya que estas operaciones tienen el impacto más significativo en el consumo general de recursos.