Evitar las limitaciones o los bloqueos en SharePoint Online

Obtenga información sobre la limitación en SharePoint Online y aprenda cómo evitar ser limitado o bloqueado. Se incluyen modelos de objetos del lado cliente (CSOM) y código REST de ejemplos, que puede usar para facilitar su tarea.

• ¿Qué es una limitación?
• Escenarios comunes de limitación en SharePoint Online
• ¿Por qué no se me diera los límites de limitación exactos?
• Límites de volumen de consultas de búsqueda al usar la autenticación de solo aplicación con permisos Sites.Read.All
• Procedimientos recomendados para tratar la limitación
• ¿Cómo decorar el tráfico para evitar las limitaciones?
• Ejemplos de código de CSOM GitHub: SharePoint Online límite
• ¿Qué debe hacer si se quedara bloqueado en SharePoint Online ?
• Recursos adicionales

¿Esto le suena familiar? Está ejecutando un proceso CSOM: por ejemplo, para migrar archivos en SharePoint Online - pero sigue obteniendo limitaciones. O peor aún, resulta bloqueado. ¿Qué está ocurriendo y qué puede hacer para detenerlo?

¿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 se llama el número de acciones de usuario o simultáneos (por secuencia de comandos o código) para evitar el uso excesivo de los 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 obtiene una limitación, tenga en cuenta que el 99 % de las veces es debido al código personalizado. Esto no significa que no haya otros modos de recibir limitaciones, solo que son menos comunes. Por ejemplo, supongamos que tiene 10 equipos y un cliente de sincronización en los 10. En cada sincronización hay 1 TB de contenido. Es probable que esto obtendría se limita a.

<a name="what-happens-when-you-get-throttled-in-sharepoint-online">¿Qué sucede cuando obtener reducidas en SharePoint Online ?

Cuando un usuario supera los límites de uso, SharePoint Online las limitaciones de las solicitudes sucesivas de esa cuenta de usuario durante un breve período. Se limita a todas las acciones de usuario mientras el acelerador está activada.

• 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 todas las demás solicitudes, incluidas las llamadas CSOM o REST, SharePoint Online devuelve código de estado HTTP 429 ("Demasiadas solicitudes") o 503 ("Servidor muy ocupado"), y se producirá un error en las solicitudes.

Si el proceso incorrecto continúa superando los límites de uso, SharePoint Online puede bloquear completamente el proceso. En este caso, no verá ninguna solicitud correcta y Microsoft le notificará del bloqueo en el Centro de mensajes de Office 365.

Limitación de aplicación

Además de la limitación por cuenta de usuario, también se aplican límites a cada aplicación del espacio empresarial. Todas las aplicaciones de SharePoint Online tienen sus propios recursos disponibles, pero cuando se ejecutan varias aplicaciones desde el mismo espacio empresarial, se comparten recursos del mismo depósito y en raras ocasiones esto podría provocar limitación de velocidad. En estos casos, SharePoint Online intentará dar prioridad a las solicitudes de usuario interactivos sobre las actividades en segundo plano.

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.

  Por ejemplo, tras migrar archivos a SharePoint Online, ejecuta una secuencia de comandos personalizada, CSOM o REST para actualizar los metadatos en los archivos. El script REST/CSOM está actualizando un gran número de archivos en una muy alta frecuencia, que desencadena la limitación de peticiones. Del mismo modo, un widget de interfaz de usuario de autocompletar que utiliza servicios REST, haciendo demasiadas llamadas a las listas durante cada operación del usuario final, también puede provocar la limitación, dependiendo de qué otras operaciones estén consumiendo recursos al mismo tiempo.

  

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

  • Está ejecutando un script de prueba de carga en SharePoint Online y se ve limitado. 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. Utilizar SharePoint y OneDrive como servicio intermedio entre Microsoft 365 y otro repositorio es un ejemplo de uso no admitido.

• Crear varios AppID para la misma aplicación

  Si las aplicaciones realizan básicamente las mismas operaciones tales como la prevención de pérdida de datos o las copias de seguridad, no es necesario que cree AppID independientes. 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.

¿Por qué no se me diera los límites de limitación exactos?

Establecer y publicar los criterios exactos de las limitaciones parece sencillo, pero de hecho daría lugar a límites más restrictivos. Supervisamos continuamente el uso de recursos de SharePoint Online. Los umbrales se ajustan en función del uso para que los usuarios puedan consumir el número máximo de recursos sin reducir la fiabilidad y el rendimiento de SharePoint Online. Asimismo, los límites de las aplicaciones se establecen en función del tráfico general del usuario, el uso y otros factores del espacio empresarial.

Por eso es tan importante que su código respete el valor del Retry-Afterencabezado HTTP; esto permite que su código se ejecute tan rápido como sea posible en un día determinado, y permite que su código se detenga "lo suficiente" si alcanza la limitación. Los ejemplos de código que se muestran más adelante en este artículo explican cómo usar el encabezado HTTP Retry-After.

Límites de volumen de consultas de búsqueda al usar la autenticación de solo aplicación con permisos Sites.Read.All

En SharePoint y OneDrive, procesamos varios miles de millones de documentos y permitimos a nuestros clientes emitir grandes volúmenes de consulta por segundo. Cuando usa las API de búsqueda de SharePoint Online con autenticación de solo aplicación y la aplicación tiene permisos Sites.Read.All (o más seguros), la aplicación se registrará con permisos completos y podrá consultar todo el contenido de SharePoint Online (incluido el contenido privado de ODB del usuario).

Queremos informar a nuestros clientes de que las consultas de búsqueda de SharePoint Online que usen este permiso estarán limitadas a 25 QPS. La consulta de búsqueda volverá con una respuesta 429 y podrá volver a intentar la consulta después de 2 minutos. Cuando espera la recuperación de 429, debe asegurarse de pausar todas las solicitudes de consulta de búsqueda que podría estar realizando en el servicio con permisos similares de solo aplicación. Realizar llamadas adicionales mientras recibe respuestas de limitaciones extenderá el tiempo que tarda la aplicación en dejar de estar limitada.

A medida que escalamos nuestro sistema, nos damos cuenta de la importancia de mejorar el sistema para ejecutarlo de forma eficiente y también para proteger el sistema y, de ahí, este cambio. Se espera que este cambio se implemente para los espacios empresariales a partir de agosto de 2020.

Procedimientos recomendados para controlar la limitación

• Reducir el número de operaciones por solicitud
• Reducir la frecuencia de llamadas.
• Elija las API de Microsoft Graph en lugar de las API CSOM y REST cuando sea posible
• 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)
• Usar el encabezado HTTP Retry-After

Microsoft Graph es una API nacida en la nube que cuenta con las últimas mejoras y optimizaciones. En general, Microsoft Graph usa 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 las aplicaciones y reducir la limitación.

Si encuentra una limitación, es necesario que aproveche el encabezado HTTP Retry-After para asegurar el mínimo retraso hasta que se quite el límite.

El encabezado HTTP Retry-After es la manera más rápida de controlar las limitaciones, ya que porque SharePoint Online determina de forma dinámica el momento adecuado para volver a intentarlo. En otras palabras, los reintentos agresivos funcionan en su contra porque, aunque las llamadas fallan, siguen acumulándose contra sus límites de uso. Seguir el encabezado HTTP Retry-After garantiza un retraso más corto.

Para obtener más información sobre formas de supervisar la actividad de SharePoint Online, consulte Diagnosticar problemas de rendimiento con SharePoint Online.

Para obtener una explicación más amplia sobre la limitación en Microsoft Cloud, vea Patrón de limitación.

¿Cómo decorar el tráfico http para evitar la limitación?

Para asegurar y mantener la alta disponibilidad, se puede limitar algo de tráfico. La limitación ocurre cuando la salud del sistema está en juego y uno de los criterios usados para la limitación es la decoración de tráfico, lo que afecta directamente a la prioridad del tráfico. El tráfico que está decorado correctamente 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 la llamada de la API de REST o CSOM a SharePoint Online. La cadena de agente de usuario debe estar en un formato específico, como se describe a continuación.

¿Cuáles son las recomendaciones?

• Si ha creado una aplicación, la recomendación es registrar y utilizar AppID y AppTitle: esto garantizará la mejor experiencia general y el mejor camino para la resolución de cualquier problema futuro. Incluya también la información de la cadena del agente de usuario como se define en el siguiente paso.

  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

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

Ejemplo de decoración de tráfico con el agente de usuario al usar el modelo de objetos del lado cliente (CSOM)

// Get access to source site
using (var ctx = new ClientContext("https://contoso.sharepoint.com/sites/team"))
{
  //Provide account and pwd for connecting to SharePoint Online
  var passWord = new SecureString();
  foreach (char c in pwd.ToCharArray()) passWord.AppendChar(c);
  ctx.Credentials = new SharePointOnlineCredentials("contoso@contoso.onmicrosoft.com", passWord);

  // Add our User Agent information
  ctx.ExecutingWebRequest += delegate (object sender, WebRequestEventArgs e)
  {
      e.WebRequestExecutor.WebRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
  };

  // Normal CSOM Call with custom User-Agent information
  Web site = ctx.Web;
  ctx.Load(site);
  ctx.ExecuteQuery();
}

Ejemplo de decoración de tráfico con el agente de usuario al usar las API de REST

El ejemplo siguiente tiene formato C#, pero se recomienda usar la información de agente de usuario similar incluso para las bibliotecas de JavaScript que se usan en las páginas de SharePoint Online.

HttpWebRequest endpointRequest = (HttpWebRequest) HttpWebRequest.Create(sharepointUrl.ToString() + "/_api/web/lists");
endpointRequest.Method = "GET";
endpointRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
endpointRequest.Accept = "application/json;odata=nometadata";
endpointRequest.Headers.Add("Authorization", "Bearer " + accessToken);
HttpWebResponse endpointResponse = (HttpWebResponse)endpointRequest.GetResponse();

Ejemplo de código CSOM: método de extensión ExecuteQueryWithIncrementalRetry

Agregue este método de extensión en una clase estática y use ExecuteQueryWithIncrementalRetry en lugar de ExecuteQuery para hacer que su código maneje la limitación de solicitudes.

public static void ExecuteQueryWithIncrementalRetry(this ClientContext clientContext, int retryCount, int delay)
{
  int retryAttempts = 0;
  int backoffInterval = delay;
  int retryAfterInterval = 0;
  bool retry = false;
  ClientRequestWrapper wrapper = null;
  if (retryCount <= 0)
    throw new ArgumentException("Provide a retry count greater than zero.");
  if (delay <= 0)
    throw new ArgumentException("Provide a delay greater than zero.");

  // Do while retry attempt is less than retry count
  while (retryAttempts < retryCount)
  {
    try
    {
      if (!retry)
      {
        clientContext.ExecuteQuery();
        return;
      }
      else
      {
        //increment the retry count
        retryAttempts++;

        // retry the previous request using wrapper
        if (wrapper != null && wrapper.Value != null)
        {
          clientContext.RetryQuery(wrapper.Value);
          return;
        }
        // retry the previous request as normal
        else
        {
          clientContext.ExecuteQuery();
          return;
        }
      }
    }
    catch (WebException ex)
    {
        var response = ex.Response as HttpWebResponse;
        // Check if request was throttled - http status code 429
        // Check is request failed due to server unavailable - http status code 503
        if (response != null && (response.StatusCode == (HttpStatusCode)429 || response.StatusCode == (HttpStatusCode)503))
        {
          wrapper = (ClientRequestWrapper)ex.Data["ClientRequest"];
          retry = true;

          // Determine the retry after value - use the `Retry-After` header when available
          string retryAfterHeader = response.GetResponseHeader("Retry-After");
          if (!string.IsNullOrEmpty(retryAfterHeader))
          {
            if (!Int32.TryParse(retryAfterHeader, out retryAfterInterval))
            {
              retryAfterInterval = backoffInterval;
            }
          }
          else
          {
            retryAfterInterval = backoffInterval;
          }

          // Delay for the requested seconds
          Thread.Sleep(retryAfterInterval * 1000);

          // Increase counters
          backoffInterval = backoffInterval * 2;
        }
        else
        {
          throw;
        }
    }
  }
  throw new MaximumRetryAttemptedException($"Maximum retry attempts {retryCount}, has be attempted.");
}

[Serializable]
public class MaximumRetryAttemptedException : Exception
{
  public MaximumRetryAttemptedException(string message) : base(message) { }
}

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

El bloqueo es la forma más extrema de limitación. Rara vez bloqueamos a un inquilino, a menos que detectemos un tráfico excesivo a largo plazo que pueda amenazar la salud general del servicio de SharePoint Online. Aplicamos bloqueos para evitar que el tráfico excesivo degrade el rendimiento y la fiabilidad de SharePoint Online. Un bloqueo, colocado en el nivel de la aplicación o del usuario, impide que se ejecute el proceso infractor hasta que se solucione el problema. Si bloqueamos su suscripción, deberá tomar medidas para modificar los procesos infractores antes de que se pueda quitar el bloqueo.

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

Consulte también

• Diagnosticar problemas de rendimiento con SharePoint Online
• Planeamiento de capacidad y pruebas de carga en SharePoint Online