Evitar las limitaciones o los bloqueos en SharePoint Online

  • Artículo

Obtenga información acerca de la limitación en SharePoint Online y aprenda a evitar quedar limitado o bloqueado.

¿Hace a esto les resulta familiar? Está ejecutando una aplicación, por ejemplo, para escanear archivos en SharePoint, pero le limitan. O peor aún, le bloquean. ¿Lo que está ocurriendo y qué puede hacer para que sea detener?

¿Qué es una limitación?

SharePoint Online utiliza limitación para mantener un rendimiento óptimo y la confiabilidad del servicio SharePoint Online. La limitación restringe el número de operaciones o llamadas de API durante un tiempo para prevenir el uso excesivo de recursos.

¿Qué sucede cuando obtener reducidas en SharePoint Online ?

Cuando se superan los límites de uso, SharePoint Online limita las solicitudes de ese cliente durante un breve periodo.

Para las solicitudes que realiza un usuario directamente en el explorador, SharePoint Online lo redirige a la página de información de limitación y se producirá un error en las solicitudes.

Para las solicitudes que realiza una aplicación, incluidas las llamadas de Microsoft Graph, CSOM o REST, SharePoint Online devuelve el código de estado HTTP 429 ("Demasiadas solicitudes") o 503 ("Servidor demasiado ocupado") y se producirá un error en las solicitudes.

  • HTTP 429 indica que la aplicación que realiza la llamada envió demasiadas solicitudes en un periodo de tiempo y superó un límite predeterminado.
  • HTTP 503 indica que el servicio no está listo para controlar la solicitud. La causa común es que el servicio está experimentando más picos de carga temporales de los esperados.

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 no respetar el Retry-After puede resultar en un aumento de la limitación.

Si la aplicación infractora sigue superando los límites de uso, SharePoint Online puede bloquear completamente la aplicación o patrones de solicitud específicos de la aplicación. En este caso, la aplicación seguirá obteniendo el código de estado HTTP 503 y Microsoft notificará al inquilino del bloque en el Centro de mensajes de Office 365.

Limitación de peticiones de usuarios

La limitación restringe el número de llamadas y operaciones realizadas colectivamente por las aplicaciones en nombre de un usuario para evitar el uso excesivo de recursos.

Sin embargo, es raro que un usuario reciba limitaciones en SharePoint Online. El servicio es sólido y está diseñado para trabajar con un alto volumen. Si se le limita, el 99 % de las veces se debe a código personalizado, como elementos web personalizados, consultas y vistas de lista complejas, o aplicaciones personalizadas ejecutadas por los usuarios. Esto no significa que no haya otros modos de recibir limitaciones, solo que son menos comunes. Por ejemplo, un usuario que sincronizando una gran cantidad de datos en 10 máquinas al mismo tiempo podría desencadenar la limitación.

Limitación de aplicación

Además de la limitación por cuenta de usuario, también se limitan las aplicaciones de un inquilino.

Cada aplicación tiene sus propios límites en un inquilino, basados en el número de licencias compradas por organización (consulte los planes enumerados en Límites de SharePoint para ver las licencias incluidas). Cada solicitud que realiza una aplicación en todos los puntos de conexión de API, incluidos Microsoft Graph, CSOM y REST, cuenta para el uso de la aplicación.

SharePoint proporciona varias API. Las distintas API tienen costos diferentes en función de la complejidad de la API. SharePoint normaliza el costo de las API y lo expresa en unidades de recursos. Los límites de aplicación también se definen mediante unidades de recursos.

En la tabla siguiente se definen los límites de unidades de recursos para una aplicación en un inquilino:

Cantidad de licencias 0 - 1 000 1 000 - 5 000 5 000 - 15 000 15 000 - 50 000 Más de 50 000
Aplicación 1 minuto 1 200 2 400 3 600 4 800 6 000
Aplicación diaria 1 200 000 2 400 000 3 600 000 4 800 000 6 000 000

Nota:

Nos reservamos el derecho a cambiar los límites de unidades de recursos.

En términos de costos de API, las API de Microsoft Graph tienen un costo unitario de recursos predeterminado por solicitud:

Unidades de recursos por solicitud Operaciones
1
  • Consulta de un solo elemento, como get item
  • Delta con un token
    		•
    2
  • Consulta de varios elementos, como enumerar elementos secundarios, excepto delta con un token
  • Creación, actualización, eliminación y carga
    		•
    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.

    Delta con un token es la forma más eficiente de examinar contenido en SharePoint. Hablamos de ello con más detalles en los procedimientos recomendados para el examen de aplicaciones. Para ayudar a las aplicaciones que sigan las instrucciones, reducimos el costo en unidades de recursos de las solicitudes delta con un token a 1 unidad de recurso, aunque se trate de una consulta de varios elementos. La solicitud delta sin un token se considera una consulta de varios elementos y cuesta 2 unidades de recursos por solicitud.

    En el procesamiento por lotes, las solicitudes en un lote son evaluadas individualmente en unidades de recursos.

    CSOM y REST no tienen un costo de unidad de recursos predeterminado y suelen consumir más unidades de recursos que las API de Microsoft Graph para lograr la misma funcionalidad. Además de los límites de unidades de recursos, CSOM y REST también están sujetos a otros límites de recursos internos, por lo que si las aplicaciones llaman a CSOM y REST, pueden experimentar más limitaciones que las descritas en este documento. Se recomienda encarecidamente elegir las API de Microsoft Graph en lugar de las API de REST y CSOM siempre que sea posible.

    Dado que los límites de la aplicación están en unidades de recursos, la tasa real de solicitudes, como las solicitudes por minuto, depende de la elección de la API de la aplicación y del costo de unidades de recursos de API correspondiente. En general, puede estimar la tasa de solicitudes mediante un promedio de 2 unidades de recursos por solicitud y dividiendo entre 2 los límites de unidades de recursos.

    Aunque cada aplicación tiene sus propios límites dentro de un inquilino y permitimos que los inquilinos ejecuten más de una aplicación, varias aplicaciones que se ejecutan en el mismo inquilino comparten los mismos recursos y, en raras ocasiones, esto puede provocar una limitación de velocidad cuando demasiadas aplicaciones envían solicitudes a la vez.

    ¿Cómo controlar las limitaciones?

    A continuación se muestra un resumen rápido de los procedimientos recomendados para controlar las limitaciones:

    • Reduzca el número de solicitudes
    • Evite picos de solicitudes
    • Elija las API de Microsoft Graph sobre CSOM y LAS API REST siempre que sea posible.
    • Use los encabezados HTTP Retry-After y RateLimit
    • Decorar el tráfico para que sepamos quién es (vea la sección de procedimientos recomendados para la decoración de tráfico, más información al respecto a continuación)

    Como se indicó anteriormente, Microsoft Graph es api nacidas en la nube que tienen las últimas mejoras y optimizaciones. En general, Microsoft Graph consume menos recursos que CSOM y REST para lograr la misma funcionalidad. Por lo tanto, la adopción de Microsoft Graph puede mejorar el rendimiento de la aplicación y reducir la limitación.

    Si queda limitado, es necesario que use el encabezado HTTP Retry-After para asegurar el mínimo retraso hasta que acabe la limitación. Los encabezados HTTP RateLimit le envían señales tempranas cuando está cerca de los límites y puede reducir proactivamente las solicitudes para evitar alcanzar el límite.

    Encabezado Retry-after

    Cuando las aplicaciones experimentan limitaciones, SharePoint Online devuelve un encabezado HTTP Retry-After en la solicitud que indica cuántos segundos debe esperar la aplicación que realiza la llamada antes de reintentar o realizar una nueva solicitud.

    Respetar el encabezado HTTP Retry-After es la manera más rápida de controlar las limitaciones, ya que SharePoint Online determina de forma dinámica el momento adecuado para volver a intentarlo.

    Las solicitudes limitadas cuentan para los límites de uso, por lo que no respetar el Retry-After puede resultar en un aumento de la limitación. En otras palabras, los reintentos agresivos juegan en su contra porque, aunque las llamadas fallen, siguen acumulándose de cara a sus límites de uso. Respetar el encabezado HTTP Retry-After garantiza el retraso más corto y reduce el derroche de la cuota en solicitudes limitadas.

    Encabezados RateLimit: vista previa

    Además del encabezado Retry-After en la respuesta de solicitudes limitadas, SharePoint Online también devuelve los encabezados RateLimit de IETF para límites seleccionados en determinadas condiciones para ayudar a las aplicaciones a administrar la limitación de velocidad. Se recomienda que las aplicaciones aprovechen estos encabezados para evitar alcanzar la limitación.

    • RateLimit-Limit contiene el límite en el intervalo actual de tiempo.
    • RateLimit-Remaining indica la cuota restante en el intervalo actual.
    • RateLimit-Reset indica el número de segundos hasta que se rellena la cuota.

    Nota:

    Estos encabezados están actualmente en versión beta y están sujetos a cambios. En el momento en que se adoptaron los encabezados, la especificación de IETF era un borrador. La implementación actual se basa en el borrador 03 de la especificación de IETF. Existe la posibilidad de cambios cuando la especificación se finalice y nos adaptaremos a ellos en el futuro.

    Los encabezados RateLimit se devuelven de la mejor forma posible, por lo que es posible que las aplicaciones no reciban los encabezados en todas las condiciones. Además, hay otros límites que no se presentan en los encabezados RateLimit, por lo que las aplicaciones se pueden limitar incluso antes de alcanzar el límite descrito en los encabezados RateLimit. A continuación se muestra la lista de límites para los que se admiten los encabezados RateLimit. Las directivas y los valores están sujetos a cambios:

    límite Condición valor del límite Descripción
    Unidad de recursos por minuto por aplicación Uso >= 80 % del límite Unidad de recurso Cuando una aplicación consume el 80 % o más del límite por minuto por aplicación, se devuelven el límite, el resto y el restablecimiento.

    A continuación se muestran algunos ejemplos que le ayudarán a comprender los encabezados RateLimit:

    • Una aplicación ha consumido el 90 % de su cuota de unidades de recursos (1 080 de 1 200) y su consumo está dentro de todos los límites que se le aplican. La solicitud se realiza correctamente y se devuelven los encabezados RateLimit.
    HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5
    • Una aplicación ha consumido el 100 % de su cuota de unidades de recursos, por lo que se limita debido a esta directiva. Se limita la solicitud y se devuelven los encabezados RateLimit. Retry-After coincide con RateLimit-Reset.
    HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31
    • Una aplicación ha consumido el 90 % de su cuota de unidades de recursos, pero su consumo ya ha alcanzado otros límites que los encabezados RateLimit no admiten. En este caso, se limita la solicitud y los encabezados RateLimit no se devuelven para evitar confusiones, aunque se cumpla la condición para devolver los encabezados.
    HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Puede encontrar información adicional en Impedir la limitación en la aplicación mediante encabezados RateLimit en SharePoint Online.

    ¿Cómo decorar el tráfico http?

    El tráfico correctamente decorado tendrá prioridad sobre el tráfico que no lo esté.

    ¿Cuál es la definición de tráfico no decorado?

    • El tráfico es no decorado si no hay ninguna cadena de agente de usuario ni AppID/AppTitle en las llamadas de las API a SharePoint Online. La cadena de agente de usuario debe estar en un formato específico, como se describe a continuación.
    • Si está desarrollando una aplicación web que se ejecuta en el explorador, la mayoría de los exploradores modernos no permiten sobrescribir la cadena del agente de usuario y no es necesario implementarla.

    ¿Cuáles son las recomendaciones?

    • Si ha creado una aplicación, se recomienda registrar y utilizar AppID y AppTitle: esto asegurará una mejor experiencia general y una mejor ruta para solucionar cualquier problema en el futuro. Incluya también información de la cadena de agente de usuario como se describe en el paso siguiente.

      Nota:

      Consulte la documentación de identidad de Microsoft, como la página Inicio rápido: Registrar una aplicación en la plataforma de identidad de Microsoft para obtener información sobre cómo crear una aplicación de Azure AD.

    • Asegúrese de incluir la cadena de agente de usuario en la llamada de la API a SharePoint con la siguiente convención de nomenclatura

    Tipo Agente de usuario Descripción
    Aplicación ISV ISV|CompanyName|AppName/Version Identificar como ISV e incluir el nombre de la empresa y el nombre de la aplicación separados por un carácter de barra vertical y, a continuación, agregar el número de versión, separado por un carácter de barra diagonal
    Aplicación empresarial NONISV|CompanyName|AppName/Version Identificar como NONISV e incluir el nombre de la empresa y el nombre de la aplicación separados por un carácter de barra vertical y, a continuación, agregar el número de versión, separado por un carácter de barra diagonal
    • Si va a crear sus propias bibliotecas de JavaScript, que se utilizan para llamar a las API de SharePoint Online, asegúrese de que incluye la información de agente de usuario para la solicitud http y, si es posible, también registre su aplicación web como tal, cuando sea adecuado.

    Nota:

    Se espera que el formato de la cadena del agente de usuario siga RFC2616, por lo que debe seguir las instrucciones anteriores sobre los separadores adecuados. También es válido anexar la cadena de agente de usuario existente con la información solicitada.

    Escenarios comunes de limitación en SharePoint Online

    Las causas más comunes de limitación en SharePoint Online por usuario son el modelo de objetos de cliente (COM) o código de Representational State Transfer (REST) que realiza acciones demasiados con demasiada frecuencia.

    • Tráfico esporádico

      La carga constante o las consultas repetitivas complejas en SharePoint Online deben ser optimizadas para conseguir un bajo impacto. Si no sigue los procedimientos recomendados para el análisis de aplicaciones que procesan archivos en masa probablemente tendrá como resultado una limitación. Estas aplicaciones incluyen motores de sincronización, proveedores de copia de seguridad, indizadores de búsqueda, motores de clasificación, herramientas de prevención de pérdida de datos y cualquier otra herramienta, que intente razonar sobre la totalidad de datos y aplicar cambios.

    • Tráfico abrumador

      Un solo proceso considerablemente supera la limitación de peticiones, de forma continua, durante un período de tiempo prolongado.

      • Usa los servicios web para crear una herramienta para sincronizar las propiedades de perfil de usuario. La herramienta actualiza las propiedades de perfil de usuario según la información de su sistema de recursos humanos (HR) de línea de negocio (LOB). La herramienta realiza llamadas en demasiado alta frecuencia.
      • Ejecuta un script de prueba de carga en SharePoint Online y experimenta limitaciones. Las pruebas de carga no están permitidas en SharePoint Online.
      • Personalizar el sitio de grupo en SharePoint Online, por ejemplo, mediante la adición de un indicador de estado en la página principal. Este indicador de estado se actualiza con frecuencia, lo que hace que la página realizar llamadas demasiados al servicio SharePoint Online: Esto desencadena la limitación de peticiones.
      • La ejecución del cliente OneDrive Sync al mismo tiempo que se ejecutan aplicaciones de migración o aplicaciones que rastrean sitios y escriben datos puede generar grandes volúmenes de solicitudes que pueden desencadenar limitaciones.

    • Casos de uso no admitidos

      El uso no admitido de SharePoint Online puede experimentar limitaciones. El uso de SharePoint y OneDrive como servicio intermedio entre Microsoft 365 y otro repositorio es un ejemplo de un caso de uso no admitido.

    • Crear varios AppID para la misma aplicación

      No cree AppID independientes en las que las aplicaciones realizan esencialmente las mismas operaciones, como por ejemplo copias de seguridad o prevención de pérdida de datos. En última instancia, las aplicaciones que se ejecutan en el mismo espacio empresarial comparten el mismo recurso de ese espacio. Anteriormente algunas aplicaciones intentaban hacerlo así para evitar la limitación de aplicaciones, pero esto acababa agotando el recurso del espacio empresarial y provocando que varias aplicaciones sufrieran una limitación dentro del espacio.

    Límites específicos del escenario

    Al usar la autenticación de solo aplicación con el permiso Sites.Read.All

    Cuando use las API de búsqueda de SharePoint Online con autenticación de solo aplicación y la aplicación que tenga el permiso Sites.Read.All (o más seguro), la aplicación se registrará con permisos completos y podrá consultar todo el contenido de SharePoint Online (incluido el contenido de OneDrive para la Empresa privado del usuario).

    Para garantizar que el servicio sigue siendo rápido y fiable, las consultas que usan este permiso se limitan a 25 solicitudes por segundo. La consulta de búsqueda devolverá una respuesta http 429. Mientras esté esperando la recuperación de la limitación, debe asegurarse de pausar todas las solicitudes de consulta de búsqueda con permisos similares de solo aplicación que podría estar realizando en el servicio. Realizar llamadas adicionales mientras recibe respuestas de limitación alargará el tiempo que tarda la aplicación en dejar de estar limitada.

    Al buscar resultados de búsqueda de personas

    Al buscar con un origen de resultados que solicita resultados de personas, podemos limitar las solicitudes que superen un límite de 25 solicitudes por segundo en toda la organización. Este límite se aplica a todas las solicitudes de REST y CSOM de búsqueda de SharePoint mediante el origen de resultados "Resultados de Personas locales" o un origen de resultados de búsqueda de personas personalizados.

    Si tiene aplicaciones o componentes que provocan que las solicitudes de búsqueda de personas se limiten, le recomendamos que:

    1. Considere si las solicitudes son necesarias para la aplicación. Por ejemplo, si usa un sitio de búsqueda personalizado que realiza muchas consultas simultáneas, compruebe si algunas de esas solicitudes se pueden quitar sin impactar significativamente en la experiencia de búsqueda de su organización. Como alternativa, puede considerar la posibilidad de probar nuestra experiencia de búsqueda de personas moderna en Búsqueda de Microsoft mediante búsquedas desde la página de inicio de SharePoint. La búsqueda de personas en la Búsqueda de Microsoft se ha optimizado para mejorar el rendimiento y obtener resultados más relevantes.
    2. Evite realizar solicitudes simultáneas. Por ejemplo, en lugar de emitir 10 solicitudes a la vez, emítalas de forma consecutiva; solo emita la siguiente consulta después de que se haya completado la anterior. Es posible que necesite considerar la posibilidad de almacenar en caché esos resultados si los necesita rápidamente, por ejemplo, para la carga de una página.
    3. Intente consolidar las solicitudes en una sola consulta. Por ejemplo, en lugar de realizar 10 consultas simultáneas para WorkEmail:user1@constoso.com, WorkEmail:user2@constoso.com,..., WorkEmail:user10@contoso.com, pruebe la consulta única, WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Considere la posibilidad de usar la API de Microsoft Graph si realmente es necesario un escenario de gran volumen de solicitudes (más de 25 solicitudes por segundo).

    ¿Qué debe hacer si se quedara bloqueado en SharePoint Online ?

    El bloqueo es la forma más extrema de limitación. Rara vez se bloquea un espacio empresarial, a menos que se detecte tráfico excesivo a largo plazo, que pueda poner en riesgo el estado general del servicio de SharePoint Online. Se aplican bloqueos para impedir que el tráfico excesivo degrade el rendimiento y la confiabilidad de SharePoint Online. Un bloqueo, que se encuentra en el nivel de la aplicación o del usuario, impide la ejecución del proceso incorrecto hasta que solucione el problema. Si se bloquea su suscripción, debe tomar medidas para modificar los procesos incorrectos, para poder quitar el bloqueo.

    Si bloqueamos su suscripción, se lo notificaremos en el Centro de mensajes de Office 365. El mensaje describe la causa del bloqueo, ofrece instrucciones sobre cómo resolver el problema en cuestión y le indica con quién ponerse en contacto para quitar el bloqueo.

    Consulte también