Límites de la API de protección de servicio

Artículo
04/09/2023

Para garantizar una disponibilidad y un rendimiento consistentes para todos, aplicamos algunos límites sobre cómo se utilizan las API. Estos límites están diseñados para detectar cuándo las aplicaciones del cliente demandan recursos del servidor de forma extraordinaria.

Los límites no afectarán a los usuarios normales de clientes interactivos. Solo las aplicaciones cliente que realizan solicitudes API extraordinarias deberían verse afectadas. Los límites le proporcionan cierto grado de protección contra aumentos aleatorios e inesperados en los volúmenes de solicitudes que ponen en peligro las características de disponibilidad y rendimiento de la plataforma Microsoft Dataverse.

Cuando una aplicación cliente realiza solicitudes extraordinariamente exigentes, Dataverse sigue el patrón común para los servicios en línea. Devolvemos un error que indica que se han realizado demasiadas solicitudes.

Con la API web, devolvemos un error 429 de demasiadas solicitudes.
Con el SDK de Dataverse para .NET, obtendrá un error OrganizationServiceFault con uno de los tres códigos de error específicos. Más información: Errores de límite de API de protección de servicio devueltos

Impacto en las aplicaciones cliente

Es responsabilidad de las aplicaciones cliente administrar los errores de límite de API de protección del servicio. Exactamente cómo administrar este error depende de la naturaleza de la aplicación.

Aplicaciones cliente interactivas

Los límites de protección del servicio son lo suficientemente altos como para que sea raro que una persona que utiliza una aplicación cliente interactiva los encuentre durante el uso normal. Sin embargo, es posible que aparezcan si la aplicación cliente permite operaciones masivas. Los desarrolladores de aplicaciones cliente deben ser conscientes de cómo se aplican los límites de API de protección del servicio y diseñar la interfaz de usuario para reducir la posibilidad de que los usuarios envíen solicitudes extremadamente exigentes al servidor. Pero aún así deben esperar que puedan ocurrir errores de límite de API de protección de servicio y estar preparados para manejarlos.

Los desarrolladores de aplicaciones cliente no deberían simplemente lanzar el error para mostrar el mensaje al usuario. El mensaje de error no está destinado a usuarios finales. Ver Reintentar operaciones para estrategias específicas.

Aplicaciones de integración de datos

Las aplicaciones diseñadas para cargar datos en Dataverse o realizar actualizaciones masivas también deben poder administrar los errores de límite de API de protección del servicio. Estas aplicaciones priorizan el rendimiento para que puedan completar su trabajo en el mínimo tiempo posible. Estas aplicaciones deben tener una estrategia para volver a intentar las operaciones. Existen varias estrategias que se pueden aplicar para obtener el máximo rendimiento. Más información: Cómo maximizar el rendimiento.

Aplicaciones de portal

Las aplicaciones del portal generalmente envían solicitudes de usuarios anónimos a través de una cuenta principal de servicio. Debido a que los límites de la API de protección del servicio se basan en cada usuario, las aplicaciones de portal pueden alcanzar los límites de la API de protección del servicio en función de la cantidad de tráfico que experimente el portal. Al igual que las aplicaciones cliente interactivas, no se espera que los errores de límite de la API de protección del servicio se muestren al usuario final del portal. Se espera que la interfaz de usuario deshabilite más solicitudes y muestre un mensaje de que el servidor está ocupado. El mensaje puede incluir la hora en que la aplicación puede comenzar a aceptar nuevas solicitudes.

Impacto en complementos y actividades de flujo de trabajo personalizadas

Los complementos y las actividades de flujo de trabajo personalizadas aplican la lógica empresarial activada por las solicitudes entrantes. Los límites de protección del servicio no se aplican a complementos y actividades de flujo de trabajo personalizadas. Los complementos y las actividades de flujo de trabajo personalizadas se cargan y se ejecutan dentro del servicio de espacio aislado. Las operaciones de Dataverse invocadas en el servicio de espacio aislado no utilizan los puntos de conexión de la API pública.

Si su aplicación realiza operaciones que desencadenan una lógica personalizada, la cantidad de solicitudes enviadas por complementos o actividades de flujo de trabajo personalizadas no se contarán para los límites de la API de protección del servicio. Sin embargo, el tiempo de cálculo adicional que suponen estas operaciones se agregará a la solicitud inicial que las activó. Este tiempo de cálculo es parte de los límites de la API de protección del servicio. Más información: Cómo se aplican los límites de API de protección del servicio

Reintentar operaciones

Cuando se produce un error de límite de API de protección del servicio, proporcionará un valor que indica la duración antes de que se puedan procesar las nuevas solicitudes del usuario.

Cuando se devuelve un error 429 de la API web, la respuesta incluirá un Retry-After con el número de segundos.
Con el SDK para .NET, se devuelve un valor TimeSpan en OrganizationServiceFault.ErrorDetails Recopilación con la clave Retry-After.

La duración de Retry-After

La duración de Retry-After dependerá de la naturaleza de las operaciones que se hayan enviado en el período de 5 minutos anterior. Cuanto más exigentes sean las solicitudes, más tiempo tardará en recuperarse el servidor.

Hoy, debido a la forma en que se evalúan los límites, puede esperar superar el número de solicitudes y los límites de tiempo de ejecución durante un período de 5 minutos antes de que los límites de la API de protección del servicio entren en vigor. Sin embargo, exceder el número de solicitudes concurrentes devolverá inmediatamente un error. Si la aplicación continúa enviando solicitudes tan exigentes, la duración se extenderá para minimizar el impacto en los recursos compartidos. Esto hará que el período de duración del reintento individual sea más largo, lo que significa que su aplicación verá períodos más largos de inactividad mientras espera. Este comportamiento puede cambiar en el futuro.

Cuando sea posible, recomendamos tratar de lograr una tasa constante comenzando con un menor número de solicitudes y aumentando gradualmente hasta que comience a alcanzar los límites de la API de protección del servicio. Después de eso, deje que el servidor le diga cuántas solicitudes puede manejar en un período de 5 minutos. Limitar número máximo de solicitudes dentro de este período de 5 minutos e ir aumentado gradualmente mantendrá baja la duración de Retry-After, optimizando su rendimiento total y minimizando los picos de recursos del servidor.

Reintentar aplicación interactiva

Si el cliente es una aplicación interactiva, debe mostrar un mensaje de que el servidor está ocupado mientras reintenta la solicitud que realizó el usuario. Es posible que desee proporcionar una opción para que el usuario cancele la operación. No permita que los usuarios envíen más solicitudes hasta que se complete la solicitud anterior que envió.

Reintentar aplicación no interactiva

Si el cliente no es interactivo, la práctica común es simplemente esperar a que pase el tiempo antes de enviar la solicitud nuevamente. Esto se hace comúnmente pausando la ejecución de la tarea actual usando Task.Delay o métodos equivalentes.

Cómo volver a intentar

A continuación, se describe cómo volver a intentar aplicaciones .NET mediante el Dataverse SDK para .NET o API web:

SDK para .NET
API web

Si usa el SDK para .NET, se recomienda que use Microsoft.Xrm.Tooling.Connector.CrmServiceClient o clases ServiceClient. Estas clases implementan los métodos IOrganizationService y puede administrar cualquier error de límite de API de protección de servicio que se devuelva.

Desde la versión 9.0.2.16 de Xrm.Tooling.Connector, se pausará automáticamente y volverá a enviar la solicitud después del período de duración de Retry-After.

Si su aplicación está utilizando actualmente el nivel bajo Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy o bien las clases Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient . Debería poder reemplazarlos con la clase CrmServiceClient o ServiceClient. OrganizationServiceProxy está en desuso.

Más información:

Si está utilizando la API web con una biblioteca de cliente, es posible que admita el comportamiento de reintento esperado para los errores 429. Consulte con el editor de la biblioteca cliente.

Si ha escrito su propia biblioteca, puede incluir comportamientos que sean similares a los incluidos en este código de muestra para una biblioteca de clases WebAPIService (C#) auxiliar.

/// <summary>
/// Specifies the Retry policies
/// </summary>
/// <param name="config">Configuration data for the service</param>
/// <returns></returns>
static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy(Config config)
{
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(httpResponseMessage => httpResponseMessage.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
      .WaitAndRetryAsync(
         retryCount: config.MaxRetries,
         sleepDurationProvider: (count, response, context) =>
         {
            int seconds;
            HttpResponseHeaders headers = response.Result.Headers;

            if (headers.Contains("Retry-After"))
            {
               seconds = int.Parse(headers.GetValues("Retry-After").FirstOrDefault());
            }
            else
            {
               seconds = (int)Math.Pow(2, count);
            }
            return TimeSpan.FromSeconds(seconds);
         },
         onRetryAsync: (_, _, _, _) => { return Task.CompletedTask; }
      );
}

En este ejemplo se usa Polly, una biblioteca de resistencia de .NET y control de errores transitorios que permite a los desarrolladores expresar políticas como Retry, Circuit Breaker, Timeout, Bulkhead Isolation y Fallback de manera fluida y segura.

Encabezados de la respuesta HTTP

Si está utilizando solicitudes HTTP con la web API, puede seguir los valores límite restantes con los siguientes encabezados de respuesta HTTP:

Encabezado	Descripción del valor
`x-ms-ratelimit-burst-remaining-xrm-requests`	El número restante de solicitudes para esta conexión
`x-ms-ratelimit-time-remaining-xrm-requests`	La duración combinada restante de todas las conexiones que usan la misma cuenta de usuario

No debe depender de estos valores para controlar la cantidad de solicitudes que envía. Están destinados a fines de depuración. Si está eliminando la cookie de afinidad, estos valores se restablecen cuando se conecta a un servidor diferente.

Cómo se aplican los límites de API de protección del servicio

Dos de los límites de la API de protección del servicio se evalúan dentro una ventana deslizante de 5 minutos (300 segundos). Si se excede cualquiera de los límites dentro de los 300 segundos anteriores, se producirá un error de límite de API de protección del servicio en las solicitudes posteriores para proteger el servicio hasta que finalice el tiempo de duración de Retry-After.

Los límites de la API de protección del servicio se evalúan por usuario. Cada usuario autenticado está limitado de forma independiente. Solo las cuentas de los usuarios que están haciendo demandas extraordinarias serán limitadas. Otros usuarios no se verán afectados.

Los límites de la API de protección del servicio se aplican en base a tres facetas:

El número de solicitudes enviadas por un usuario.
El tiempo de ejecución combinado necesario para procesar las solicitudes enviadas por un usuario.
El número de solicitudes simultáneas enviadas por un usuario.

Si el único límite fuera el número de solicitudes enviadas por un usuario, sería posible omitirlo. Las otras facetas se agregaron para contrarrestar estos intentos. Por ejemplo:

Puede enviar menos solicitudes si las agrupa en operaciones por lotes.
- El límite de tiempo de ejecución combinado contrarrestará esto.
En lugar de enviar solicitudes individualmente de forma sucesiva, puede enviar una gran cantidad de solicitudes simultáneas antes de que se apliquen los límites de la API de protección del servicio.
- El límite de solicitud simultánea contrarrestará esto.

Cada servidor web disponible para su entorno impondrá estos límites de forma independiente. La mayoría de los entornos tendrán más de un servidor web. Los entornos de prueba solo tienen asignado un único servidor web. La cantidad real de servidores web que están disponibles para su entorno depende de múltiples factores que forman parte del servicio administrado que brindamos. Uno de los factores es cuántas licencias de usuario ha comprado.

La siguiente tabla describe los límites de API de protección del servicio predeterminados que se aplican por servidor web:

Medida	Descripción	Límite por servidor web
Número de solicitudes	El número acumulado de solicitudes realizadas por el usuario	6000 dentro de la ventana deslizante de 5 minutos
Tiempo de ejecución	El tiempo de ejecución combinado de todas las solicitudes realizadas por el usuario	20 minutos (1200 segundos) dentro de la ventana deslizante de 5 minutos
Número de solicitudes simultáneas	El número de solicitudes simultáneas realizadas por el usuario	52 o superior

Importante

Estos límites están sujetos a cambios y pueden variar entre diferentes entornos. Estos números representan valores predeterminados y se proporcionan para darle una idea de qué valores puede esperar.

Errores de límite de API de protección del servicio devueltos

Esta sección describe los tres tipos de errores de límite de API de protección del servicio que se pueden devolver, así como los factores que causan estos errores y las posibles estrategias de mitigación.

El Código de error es el valor de error numérico devuelto por el SDK para .NET OrganizationServiceFault.ErrorDetails.
El Código hexadecimal es el valor de error hexadecimal devuelto por la API web.

Número de solicitudes

Este límite cuenta el número total de solicitudes durante el período anterior de 300 segundos.

Código de error	Código hexadecimal	Mensaje
`-2147015902`	`0x80072322`	`Number of requests exceeded the limit of 6000 over time window of 300 seconds.`

No se espera que un usuario típico de una aplicación interactiva pueda enviar 1200 solicitudes por minuto para superar este límite, a menos que la aplicación permita a los usuarios realizar operaciones masivas.

Por ejemplo, si una vista de lista permite la selección de 250 registros a la vez y permite que un usuario realice alguna operación en todos estos registros, el usuario necesitaría realizar esta operación 24 veces en un lapso de 300 segundos. El usuario necesitaría completar la operación en cada lista en 12,5 segundos.

Si su aplicación proporciona esta función, debe considerar algunas de las siguientes estrategias:

Disminuyendo el número total de registros que se pueden seleccionar en una lista. Si el número de elementos que se muestran en una lista se reduce a 50, el usuario necesitaría realizar esta operación 120 veces en 300 segundos. El usuario tendría que completar la operación en cada lista en 2,5 segundos.
Combine las operaciones seleccionadas en un lote. Un lote puede contener hasta 1000 operaciones y evitará el límite de la cantidad de solicitudes. Sin embargo, deberá estar preparado para el límite del tiempo de ejecución.

Tiempo de ejecución

Este límite rastrea el tiempo de ejecución combinado de las solicitudes entrantes durante el período anterior de 300 segundos.

Código de error	Código hexadecimal	Mensaje
`-2147015903`	`0x80072321`	`Combined execution time of incoming requests exceeded limit of 1,200,000 milliseconds over time window of 300 seconds. Decrease number of concurrent requests or reduce the duration of requests and try again later.`

Algunas operaciones requieren más recursos que otras. Las operaciones por lotes, la importación de soluciones y las consultas altamente complejas pueden ser muy exigentes. Estas operaciones también pueden realizarse simultáneamente en solicitudes concurrentes. Por lo tanto, dentro de la ventana de 5 minutos es posible solicitar operaciones que requerirán más de 20 minutos de tiempo de cálculo combinado.

Este límite se puede encontrar cuando se utilizan estrategias que utilizan operaciones por lotes y solicitudes simultáneas para evitar el límite de número de solicitudes.

Solicitudes simultáneas

Este límite lleva el seguimiento del número de solicitudes simultáneas.

Código de error	Código hexadecimal	Publicación
`-2147015898`	`0x80072326`	`Number of concurrent requests exceeded the limit of 52.`

Las aplicaciones del cliente no se limitan a enviar solicitudes individuales de forma secuencial. El cliente puede aplicar patrones de programación paralela o varios métodos para enviar múltiples solicitudes simultáneamente. El servidor puede detectar cuando responde a múltiples solicitudes del mismo usuario simultáneamente. Si se supera este número de solicitudes simultáneas, se generará este error. El límite puede ser superior a 52 en algunos casos.

Enviar solicitudes simultáneas puede ser una parte clave de una estrategia para maximizar el rendimiento, pero es importante mantenerlo bajo control. Cuando usas Programación en paralelo en .NET, el grado predeterminado de paralelismo depende del número de núcleos de CPU en el servidor que ejecutan el código. No debe superar el límite. La propiedad ParallelOptions.MaxDegreeOfParallelism se puede configurar para definir un número máximo de tareas concurrentes.

Más información: Enviar solicitudes paralelas

Cómo maximizar el rendimiento

Cuando tiene una aplicación que debe priorizar el rendimiento para mover la mayor cantidad de datos en el período más corto, existen algunas estrategias que puede aplicar.

Deje que el servidor le diga cuánto puede asumir.

No intente calcular cuántas solicitudes enviar a la vez. Cada entorno puede ser diferente. Aumente gradualmente la tasa de envío de solicitudes hasta que comience a alcanzar los límites y luego depende del valor Retry-After del límite de API de protección del servicio para indicarle cuándo enviar más. Este valor mantendrá su rendimiento total en el nivel más alto posible.

Usar varios subprocesos

El límite superior en el número de subprocesos simultáneas es algo que su aplicación puede usar para tener una mejora significativa en el rendimiento. Esto es cierto si sus operaciones individuales son relativamente rápidas. Dependiendo de la naturaleza de los datos que está procesando, es posible que deba ajustar el número de subprocesos para obtener un rendimiento óptimo. Más información: Enviar solicitudes paralelas

Evitar procesamientos por lotes grandes

El procesamiento por lotes se refiere al envío de múltiples operaciones en una sola solicitud.

La mayoría de los escenarios serán más rápidos enviando solicitudes individuales con un alto grado de paralelismo. Si cree que el tamaño del lote puede mejorar el rendimiento, es mejor comenzar con un tamaño de lote pequeño de 10 y aumentar la simultaneidad hasta que comience a obtener errores de límite de API de protección del servicio que tendrá que volver a intentar.

Con el SDK para .NET, esto significa usar ExecuteMultipleRequest, que normalmente permite enviar hasta 1000 operaciones en una solicitud. La principal ventaja que proporciona es que reduce la cantidad total de carga útil XML que debe enviarse por cable. Esto proporciona alguna ventaja de rendimiento cuando la latencia de la red es un problema. Para los límites de protección del servicio, aumenta el tiempo total de ejecución por solicitud. Los lotes de mayor tamaño aumentan la posibilidad de que encuentre límites de tiempo de ejecución en lugar de límites en el número de solicitudes.

En el pasado, las operaciones de ExecuteMultiple se limitaban a solo 2 a la vez debido al impacto que esto podría tener en el rendimiento. Este ya no es el caso, porque los límites de API de tiempo de ejecución de protección de servicio han hecho que ese límite sea redundante.

Cuando se usa la API web, la carga útil JSON más pequeña enviada por cable para solicitudes individuales significa que la latencia de la red no es un problema. Más información: Ejecutar operaciones por lotes mediante la API web

Nota

Las operaciones por lotes no son una estrategia válida para eludir los límites de derechos. Los límites de API de protección del servicio y los límites de derechos se evalúan por separado. Los límites de derechos se basan en operaciones CRUD y se acumulan en función de si se incluyen o no en una operación por lotes. Más información: Limitaciones de derechos

Estrategias para administrar los límites de API de protección del servicio

Esta sección describe formas en que puede diseñar sus clientes y sistemas para evitar errores de límite de API de protección del servicio. También puede considerar cómo administra sus licencias para reducir el impacto.

Actualizar la aplicación cliente

Los límites de la API de protección de servicios se han aplicado a Dataverse desde 2018, pero hay muchas aplicaciones cliente escritas antes de que existieran estos límites. Estos clientes no esperaban estos errores y no pueden administrar los errores correctamente. Debe actualizar estas aplicaciones y aplicar los patrones a las operaciones de reintento descritas anteriormente.

Avanzar hacia la integración en tiempo real

Recuerde que el punto principal de los límites de la API de protección del servicio es suavizar el impacto de las solicitudes altamente exigentes que se producen en un corto período de tiempo. Si sus procesos comerciales actuales dependen de grandes trabajos periódicos durante la noche, semanales o mensuales que intentan procesar grandes cantidades de datos en un corto período de tiempo, considere cómo podría habilitar una estrategia de integración de datos en tiempo real. Si puede alejarse de los procesos que requieren operaciones altamente exigentes, puede reducir el impacto que tendrán los límites de protección del servicio.

Preguntas frecuentes

Esta sección incluye preguntas frecuentes. Si tiene preguntas que no se responden, publíquelas usando el botón Comentarios en la parte inferior de esta página para enviar comentarios sobre esta página.

Estoy usando una aplicación ETL que autoricé. ¿Cómo obtengo un rendimiento óptimo?

Trabaje con el proveedor de la aplicación ETL para conocer qué configuraciones se aplican. Asegúrese de estar utilizando una versión del producto que admita el comportamiento Retry-After.

¿Se aplican estos límites a la búsqueda de Dataverse?

No. La búsqueda nativa de Dataverse es una API diferente (api/search en vez de api/data) y tiene reglas diferentes. Al usar la API de búsqueda de Dataverse, hay un límite de limitación de una solicitud por segundo para cada usuario.

Más información: Límites de protección de servicios de búsqueda de Dataverse

¿Cómo se aplican estos límites a la cantidad de solicitudes a las que tiene derecho un usuario cada día?

Estos límites no están relacionados con los límites de derechos. Más información: Limitaciones de derechos

¿Se aplican los límites de manera diferente para los usuarios de la aplicación?

No. Los límites se aplican a todos los usuarios de la misma manera.

Consulte también

Administrar Power Platform / Licencias y gestión de licencias / Límites de solicitudes y asignaciones
Información general sobre los límites de API de Dataverse
Usar la API web de Dataverse
Utilice el Dataverse SDK para .NET