Compartir vía

Límites de frecuencia y uso

  • Artículo

Azure DevOps Services

Azure DevOps Services usa servicios multiinquilino para reducir los costos y mejorar el rendimiento. Este diseño deja a los usuarios vulnerables a problemas de rendimiento e incluso interrupciones cuando otros usuarios de sus recursos compartidos tienen picos en su consumo. Por lo tanto, Azure DevOps limita los recursos que los usuarios pueden consumir y la cantidad de solicitudes que pueden realizar en determinados comandos. Cuando se superan estos límites, es posible que las solicitudes futuras se retrasen o bloqueen.

Para obtener más información, consulte Límites de Git y Procedimientos recomendados para evitar alcanzar los límites de velocidad.

Límite de consumo global

Azure DevOps actualmente tiene un límite de consumo global, que retrasa las solicitudes de usuarios individuales más allá de un umbral cuando los recursos compartidos están en peligro de sobrecargarse. Este límite se centra exclusivamente en evitar interrupciones cuando los recursos compartidos están cerca de sobrecargarse. Normalmente, los usuarios individuales solo obtienen solicitudes retrasadas cuando se produce uno de los siguientes incidentes:

  • Uno de sus recursos compartidos está en riesgo de sobrecargarse
  • Su uso personal supera los 200 veces el consumo de un usuario típico dentro de un período de cinco minutos (deslizante)

La cantidad del retraso depende del nivel sostenido de consumo del usuario. Los retrasos van desde unos pocos milisegundos por solicitud hasta 30 segundos. Una vez que el consumo va a cero o el recurso ya no está sobrecargado, los retrasos se detienen en cinco minutos. Si el consumo sigue siendo alto, es posible que los retrasos continúen indefinidamente para proteger el recurso.

Cuando una solicitud de usuario se retrasa por una cantidad significativa, ese usuario recibe un correo electrónico y un banner de advertencia en la web. Para la cuenta de servicio de compilación y otros sin una dirección de correo electrónico, los miembros del grupo colección de proyectos Administración istrators obtienen el correo electrónico. Para más información, consulte Supervisión del uso.

Cuando se bloquean las solicitudes de un usuario individual, se reciben respuestas con código HTTP 429 (demasiadas solicitudes), con un mensaje similar al siguiente:

TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.

Unidades de rendimiento (TTU) de Azure DevOps

Los usuarios de Azure DevOps consumen muchos recursos compartidos y el consumo depende de los siguientes factores:

  • La carga de un gran número de archivos en el control de versiones crea una gran cantidad de carga en bases de datos y cuentas de almacenamiento.
  • Las consultas complejas de seguimiento de elementos de trabajo crean carga de base de datos en función del número de elementos de trabajo que buscan en ellas.
  • Compila la carga de la unidad mediante la descarga de archivos del control de versiones, lo que genera la salida del registro.
  • Todas las operaciones consumen CPU y memoria en varias partes del servicio

Para dar cabida, el consumo de recursos de Azure DevOps se expresa en unidades abstractas denominadas unidades de rendimiento de Azure DevOps o TTU. Las TTU incorporan finalmente una combinación de los siguientes elementos:

  • DTU de Azure SQL Database como medida del consumo de base de datos
  • Cpu, memoria y E/S del agente de trabajo de la aplicación como medida del consumo de proceso
  • Ancho de banda de Azure Storage como medida del consumo de almacenamiento

Por ahora, las TTU se centran principalmente en las DTU de Azure SQL Database, ya que las bases de datos de Azure SQL son los recursos compartidos que suelen sobrecargar el consumo excesivo. Un único TSTU es la carga media que esperamos que un único usuario normal de Azure DevOps genere por cinco minutos. Los usuarios normales también generan picos de carga. Estos picos suelen ser de 10 o menos TTU por cinco minutos. Con menos frecuencia, los picos van tan altos como 100 TTU.

El límite de consumo global es de 200 TTU dentro de un período deslizante de cinco minutos.

Se recomienda que responda al menos al Retry-After encabezado. Si detecta un Retry-After encabezado en cualquier respuesta, espere hasta que pase algún tiempo antes de enviar otra solicitud. Esto ayuda a la aplicación cliente a experimentar menos retrasos aplicados. Tenga en cuenta que la respuesta es 200, por lo que no es necesario aplicar lógica de reintento a la solicitud.

Si es posible, se recomienda X-RateLimit-Remaining supervisar los encabezados y X-RateLimit-Limit . Si lo hace, podrá aproximarse a la rapidez con la que se aproxima al umbral de retraso. El cliente puede reaccionar de forma inteligente y distribuir sus solicitudes a lo largo del tiempo.

Nota:

Las identidades que usan las herramientas y las aplicaciones para integrarse con Azure DevOps pueden necesitar límites de uso y velocidad más altos más allá del límite de consumo permitido de vez en cuando. Puede obtener límites de uso y velocidad adicionales asignando el nivel de acceso Básico + Planes de prueba a las identidades deseadas usadas por la aplicación. Una vez que se cumplan las necesidades de límites de velocidad más altos, puede volver al nivel de acceso que usó la identidad. Se le cobra por el costo del nivel de acceso Básico + Test Plans solo por el tiempo que se asigna a la identidad.

Las identidades que ya están asignadas a una suscripción de Visual Studio Enterprise no se pueden asignar al nivel de acceso Basic + Test Plans hasta que se quiten.

Pipelines

La limitación de velocidad es similar para Azure Pipelines. Cada canalización se trata como una entidad individual con su propio consumo de recursos al que se realiza un seguimiento. Incluso si los agentes de compilación se hospedan automáticamente, generan carga en forma de clonación y envío de registros.

Se aplica un límite de 200 TSTU para una canalización individual en una ventana deslizante de 5 minutos. Este límite es el mismo que el límite de consumo global para los usuarios. Si una canalización se retrasa o bloquea mediante la limitación de velocidad, aparece un mensaje en los registros adjuntos.

Experiencia de cliente de API

Cuando las solicitudes se retrasan o bloquean, Azure DevOps devuelve encabezados de respuesta para ayudar a los clientes de API a reaccionar. Aunque no está totalmente estandarizado, estos encabezados se alinean ampliamente con otros servicios populares.

En la tabla siguiente se enumeran los encabezados disponibles y lo que significan. Excepto , X-RateLimit-Delaytodos estos encabezados se envían antes de que las solicitudes empiecen a retrasarse. Este diseño ofrece a los clientes la oportunidad de ralentizar proactivamente su tasa de solicitudes.

Nombre de encabezado

Descripción

Retry-After

El encabezado especificado por RFC 6585 enviado para indicarle cuánto tiempo debe esperar antes de enviar la siguiente solicitud para que se quede por debajo del umbral de detección. Unidades: segundos.

X-RateLimit-Resource

Encabezado personalizado que indica el servicio y el tipo de umbral alcanzado. Los tipos de umbral y los nombres de servicio pueden variar con el tiempo y sin advertencia. Se recomienda mostrar esta cadena a un usuario, pero no confiar en ella para el cálculo.

X-RateLimit-Delay

Cuánto tiempo se retrasó la solicitud. Unidades: segundos con hasta tres posiciones decimales (milisegundos).

X-RateLimit-Limit

Número total de TTU permitidos antes de imponer retrasos.

X-RateLimit-Remaining

Número de TTU restantes antes de retrasarse. Si las solicitudes ya se retrasan o bloquean, es 0.

X-RateLimit-Reset

Hora en la que, si todo el consumo de recursos se detuvo inmediatamente, el uso de seguimiento volvería a 0 TTU. Expresado en la época de Unix.

Seguimiento del trabajo, proceso y límites del proyecto

Azure DevOps impone límites para el número de proyectos que puede tener en una organización y el número de equipos que puede tener en cada proyecto. Tenga en cuenta también los límites de los elementos de trabajo, las consultas, los trabajos pendientes, los paneles, los paneles, etc. Para obtener más información, consulte Seguimiento del trabajo, procesos y límites del proyecto.

Wiki

Además de los límites habituales del repositorio, las wikis definidas para un proyecto se limitan a 25 MB por archivo único.

Conexiones de servicio

No hay límites por proyecto colocados en la creación de conexiones de servicio. Sin embargo, puede haber límites, que se imponen a través del identificador de Entra de Microsoft. Para más información, consulte los artículos siguientes: