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 usa la limitación para mantener el rendimiento y la confiabilidad óptimos del servicio SharePoint Online. La limitación limita el número de llamadas o operaciones de API dentro de un período de tiempo para evitar 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 limita 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:

Microsoft se reserva el derecho de cambiar los límites de la unidad de recursos.

Para aplicaciones multiinquilino:

  1. Cada inquilino que hospeda la aplicación se considera distinto, funciona de forma independiente de los demás. Por lo tanto, cada aplicación está sujeta a sus propios límites de uso dentro de cada inquilino tal como se definió anteriormente.
  2. El consumo de unidades de recursos por parte de la aplicación se medirá por inquilino y por aplicación. Esto garantiza que cada par inquilino-aplicación permanece dentro de los límites de recursos permitidos especificados para ese inquilino determinado.
  3. Si la aplicación alcanza su límite de recursos dentro de un inquilino, esta repetición no afectará a otras instancias de la aplicación que operan en inquilinos diferentes. El uso de recursos de cada inquilino está aislado, lo que evita el impacto entre inquilinos.

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
  • Descargar archivo del elemento de unidad
    		•
    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 manera más eficaz de examinar el contenido en SharePoint y hablamos más detalladamente sobre los procedimientos recomendados para examinar 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 unidad 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 los límites descritos 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 unidad de recurso 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 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 el mismo cubo de recursos y, en raras ocasiones, puede provocar una limitación de velocidad cuando demasiadas aplicaciones envían solicitudes en ese momento.

    ¿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 funcionan contra las aplicaciones de llamada porque, aunque las llamadas no se realizan correctamente, siguen contando para los 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 Retry-After encabezado en la respuesta a solicitudes limitadas, SharePoint Online también devuelve los encabezados RateLimit de IETF para los 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 de 1 minuto de la aplicación Uso >= 80 % del límite Unidad de recurso Cuando una aplicación consume el 80 % o más del límite de 1 minuto de la 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 User-Agent 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 la información de cadena del Agente de usuario tal como se define 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 User-Agent en la llamada API a SharePoint con la siguiente convención de nomenclatura.

    Tipo Agente de usuario Descripción
    Aplicación ISV ISV|CompanyName|AppName/Version Identifique como ISV e incluya el nombre de la empresa, el nombre de la aplicación separado por un carácter de canalización y, a continuación, agregue 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 compilar sus propias bibliotecas de JavaScript, que se usan para llamar a las API de SharePoint Online, asegúrese de incluir la información de User-Agent en la solicitud HTTP y, potencialmente, registrar la aplicación web también como una aplicación, 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 está bien 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 copias de seguridad, indexadores 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 los datos y aplicarles cambios.

    • Tráfico abrumador

      Un único proceso supera drásticamente los límites de limitación, continuamente, durante un largo período.

      • 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 inquilino comparten el mismo recurso que el inquilino. 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 se usan las API de búsqueda de SharePoint Online con autenticación de solo aplicación y la aplicación que tiene el permiso Sites.Read.All (o más seguro), la aplicación se registrará con permisos completos y se le permitirá consultar todo el contenido de SharePoint Online (incluido el contenido privado de OneDrive para la Empresa 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 mediante permisos de usuario delegados

    La búsqueda con permisos de usuario delegados se produce cuando una aplicación envía una solicitud de consulta de búsqueda con los permisos del usuario que ha iniciado sesión. Los ejemplos de solicitudes delegadas son los siguientes: el cuadro de búsqueda en una página de SharePoint, un elemento web basado en búsqueda o una aplicación personalizada incrustada en una página de SharePoint y una consulta de flujo de trabajo de Power Automate para obtener información de elementos.

    Para garantizar la estabilidad del servicio, el servicio limitará las solicitudes de usuario delegado que superen las 10 solicitudes por segundo por usuario. Este límite por usuario se agrega en todas las solicitudes de todas las aplicaciones. Si un único usuario envía más de 10 solicitudes de consulta de búsqueda por segundo, se devuelve un HTTP 429. La aplicación solicitante debe esperar la duración del tiempo de espera especificado en el encabezado de respuesta antes de enviar solicitudes posteriores. Al diseñar aplicaciones basadas en búsquedas, páginas de SharePoint y flujos de trabajo, los implementadores deben asegurarse de que la página y la aplicación no superen las 10 solicitudes por segundo en total y controlar las respuestas de limitación 429. Para obtener más información e instrucciones sobre el diseño de páginas y la optimización de búsqueda, vea Optimizar solicitudes de búsqueda en páginas de sitios modernos de SharePoint Online y Usar la herramienta de diagnóstico de páginas para SharePoint Online.

    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 personalizado.

    Si tiene aplicaciones o componentes que están provocando que las solicitudes de búsqueda de personas se limite, se recomienda:

    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 ningún impacto significativo 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 todas a la vez, emitalas consecutivamente: 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).

    Al acceder a sitios de OneDrive

    Cuando un cliente realiza intentos excesivos de acceder a muchas colecciones de sitios de OneDrive que no existen, es posible que limitemos las solicitudes de la dirección IP de ese cliente. El cliente recibirá una respuesta HTTP 429 al acceder a cualquier colección de sitios de OneDrive durante el período de limitación.

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

    El bloqueo es la forma más extrema de limitación. Rara vez bloqueamos un inquilino a menos que detectemos tráfico excesivo a largo plazo que pueda poner en peligro el estado general del servicio 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