Descripción de los límites y los patrones de llamada

Se aplica a: Desarrollador

Use este artículo para planear patrones de llamada de SharePoint Embedded antes de compilar operaciones de contenido y contenedor de alto volumen. SharePoint Embedded expresa el rendimiento como unidades de recursos por minuto (un modelo de costo de solicitud normalizado) en lugar de como una tasa fija de solicitudes por segundo; En la sección Límites de velocidad de API se explica cómo traducir las unidades de recursos a una tasa de solicitudes esperada.

Los límites marcados con * se pueden aumentar a petición a través del soporte técnico de Microsoft o el contacto de incorporación de SharePoint Embedded; planee el límite predeterminado y solicite un aumento antes de abordarlo en producción.

Limitar categorías

Los límites de SharePoint Embedded afectan a:

  • *Recuentos de tipos de contenedor
  • *Recuentos de contenedores
  • Almacenamiento por tipo de contenedor y contenedor
  • Archivos y carpetas
  • Permissions
  • Tamaño de archivos
  • Recuento de versiones
  • *Límites de velocidad de API
  • *Solicitudes por aplicación, contenedor y usuario

Nota:

Estos límites pueden cambiar. Compruebe los límites actuales antes de iniciarse en producción.

Límites de tamaño

SharePoint Embedded aplica los siguientes límites de tamaño.

Recurso Límite
Tipos de contenedor que un inquilino de asociado puede crear 25*
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*
Files y carpetas por contenedor 30 M
Almacenamiento por contenedor 25 TB
Files 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

Un asterisco (*) indica un límite que puede solicitar para aumentar.

De los tipos de contenedor que crea un inquilino, uno puede ser un tipo de contenedor de prueba gratuita para el desarrollo y las pruebas, y el resto son tipos de contenedor estándar (facturados). Los nuevos inquilinos comienzan con un valor predeterminado inferior que se puede generar a petición. Para obtener detalles de prueba frente a estándar, consulte Creación y configuración de un tipo de contenedor.

Diseño de los límites de tipo de contenedor

Una aplicación puede ser propietaria de un tipo de contenedor.

No modele cada cliente, proyecto, área de trabajo o usuario como un tipo de contenedor independiente.

Use contenedores para instancias de almacenamiento de aplicaciones dentro del tipo de contenedor.

Elija un tipo de contenedor para el comportamiento de nivel de aplicación, la relación de acceso y la responsabilidad de facturación.

Para el planeamiento de tipos de contenedor, consulte Descripción de los tipos de contenedor y los contenedores.

Diseño de límites de contenedor

Los contenedores proporcionan el límite de almacenamiento y seguridad.

Planee cuántos contenedores puede crear cada inquilino que consume.

Tenga en cuenta los contenedores activos y cualquier ciclo de vida de contenedor eliminado que pueda afectar a las cuotas o al almacenamiento.

Mantenga los límites del contenedor alineados con los requisitos de acceso, ciclo de vida y gobernanza.

Diseño de los límites de permisos

SharePoint Embedded permite hasta 5000 archivos y carpetas con permisos adicionales por contenedor.

Evite diseñar todos los archivos o carpetas para que tengan permisos únicos cuando un modelo de nivel de contenedor o de carpeta sea suficiente.

Use la pertenencia a contenedores y los roles siempre que sea posible.

Para conocer los conceptos de permisos, consulte Planear la autenticación y los permisos.

Respuestas de limitación

Cuando las aplicaciones alcanzan los límites del servicio, SharePoint Embedded puede devolver:

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

Ambas respuestas incluyen un Retry-After encabezado.

El encabezado indica a la aplicación cuánto tiempo debe esperar antes de reintentar o realizar una nueva solicitud.

Importante

Las solicitudes limitadas cuentan para los límites de uso. Si omite Retry-After, la aplicación puede provocar más limitaciones.

Guía de reintento

Implemente la lógica de reintento que:

  • Detecta HTTP 429 y 503.
  • Lee el Retry-After encabezado.
  • Espera la duración especificada antes de reintentar.
  • Reduce la simultaneidad después de la limitación.
  • Evita bucles de reintento inmediatos.
  • Evita los picos de solicitud después de un período de espera.

Use reintentos delimitados y muestre errores persistentes en la telemetría de las operaciones. Para obtener instrucciones generales sobre cómo controlar las respuestas de limitación, consulte Guía de limitación de Microsoft Graph.

Guía de simultaneidad

Reduzca el número de solicitudes simultáneas cuando se produce la limitación.

Evite los patrones de ráfaga que envían muchas solicitudes al mismo instante.

Distribuir el trabajo a lo largo del tiempo al procesar grandes conjuntos de contenedores o archivos.

Use colas o trabajos en segundo plano para suavizar el tráfico.

Priorice las operaciones visibles por el usuario sobre el mantenimiento en segundo plano cuando esté cerca de los límites.

Unidades de recursos de API

Las distintas API tienen costos diferentes en función de la funcionalidad y la complejidad.

El costo se normaliza y se expresa como unidades de recursos.

Los límites de velocidad de API también se definen mediante unidades de recursos.

Cada solicitud cuesta unidades de recursos en función de su complejidad:

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, incluido $expand=permissions.

Nota:

Los costos de unidad de recursos pueden cambiar.

Límites de velocidad de API

SharePoint Embedded aplica estos límites de velocidad de API.

Recurso Límite
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

Un asterisco (*) indica un límite que puede solicitar para aumentar.

Los límites de la aplicación se definen en unidades de recursos.

Las solicitudes reales por minuto dependen de las API a las que llame y de su costo de unidad de recursos.

Para calcular la tasa de solicitudes, promedia unas dos unidades de recursos por solicitud y divide el límite de unidades de recursos de la aplicación en dos.

Limitación de la velocidad de creación de contenedores

Por inquilino de consumo y durante las horas punta del inquilino, la creación de contenedores se limita a 5 contenedores nuevos por segundo. Las solicitudes que superen este límite tienen una velocidad limitada. Fuera de las horas punta, los contenedores se pueden crear a una velocidad más rápida.

Costos de operación de permisos

Las operaciones de recursos de permisos tienen un mayor costo de unidad de recursos.

Las operaciones que incluyen $expand=permissions aparecen en cinco unidades de recursos.

Reduzca la expansión innecesaria de permisos.

Las decisiones derivadas de permisos de caché solo cuando son seguras para el modelo de seguridad.

Actualice los datos de permisos cuando se produzcan cambios en la pertenencia o el rol.

Consideraciones sobre el procesamiento por lotes

El procesamiento por lotes puede reducir la sobrecarga del cliente, pero no elimina los límites del servicio ni el impacto en la facturación.

Cuente cada operación subyacente cuando calcule el consumo de la unidad de recursos y el costo de transacción.

Evite crear lotes que concentren demasiado trabajo en un contenedor, aplicación, inquilino o usuario en un intervalo corto.

Respetar las respuestas de limitación para las operaciones por lotes según los detalles de respuesta devueltos por la plataforma.

Consideraciones de rendimiento

Diseño para:

  • Menos llamadas con permisos intensivos.
  • Simultaneidad predecible.
  • Sincronización incremental.
  • Retroceso después de la limitación.
  • Separación del trabajo en primer plano y en segundo plano.
  • Equidad de nivel de inquilino para aplicaciones multiinquilino.
  • Supervisión de la tasa de solicitudes, los códigos de respuesta y la latencia.

Para ver el impacto en la facturación de las transacciones de API, consulte Elegir un modelo de facturación.

Supervisión operativa

Seguimiento:

  • HTTP 429 y 503 tasas de respuesta.
  • Recuentos de reintentos y duraciones de espera.
  • Operaciones que consumen muchos recursos.
  • Solicitudes por aplicación, inquilino, usuario y contenedor.
  • Longitud de la cola de trabajos en segundo plano.
  • Crecimiento del almacenamiento por contenedor e inquilino.
  • Frecuencia de operación de permisos.

Use estas señales para optimizar la simultaneidad e identificar los inquilinos o flujos de trabajo que necesitan cambios de diseño.

Lista de comprobación de la planificación

  • Confirme los límites de tamaño actuales antes del inicio de producción.
  • Modele contenedores en lugar de crear muchos tipos de contenedor.
  • Calcule el almacenamiento por contenedor y por inquilino consumidor.
  • Calcule los recuentos de archivos y carpetas.
  • Evite permisos aditivos innecesarios.
  • Implemente Retry-After el control para 429 y 503.
  • Limitar la simultaneidad y evitar picos.
  • Calcule el uso de la unidad de recursos por tipo de operación.
  • Reduzca las operaciones con permisos intensivos.
  • Supervisión de la limitación y la latencia.
  • Incluir el impacto en la facturación en el diseño de api.

Pasos siguientes

Empezar a compilar con inicio rápido: Compilación de la primera aplicación con VS Code.

  • Last updated on