Límites de frecuencia

Recomendaciones

Se recomienda que responda al menos al Retry-After encabezado . Si detecta un encabezado en cualquier respuesta, espere hasta que haya transcurrido esa cantidad de tiempo Retry-After antes de enviar otra solicitud. Esto ayuda a la aplicación cliente a experimentar menos retrasos forzados. 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 supervisar los encabezados X-RateLimit-RemainingX-RateLimit-Limit y .

Esto le permite aproximarse a la rapidez con la que se está aproximando al umbral de retraso.

El cliente puede reaccionar de forma inteligente al distribuir sus solicitudes a lo largo del tiempo.

Azure DevOps Services

Azure DevOps, al igual que muchas soluciones de software como servicio, usa multiinquilino para reducir los costos y mejorar el rendimiento. Este diseño deja a los usuarios vulnerables a problemas de rendimiento e incluso a interrupciones cuando otros usuarios, de sus recursos compartidos, tienen picos en su consumo. Para evitar estos problemas, Azure DevOps limita los recursos que los usuarios pueden consumir y la cantidad de solicitudes que pueden realizar a determinados comandos. Cuando se superan estos límites, las solicitudes futuras pueden retrasarse o bloquearse.

Cuando las solicitudes de un usuario se retrasan en una cantidad significativa, ese usuario recibe un correo electrónico y ve un banner de advertencia en la web. Para la cuenta de servicio de compilación y otras sin una dirección de correo electrónico, los miembros del grupo administradores de Project recopilación obtienen el correo electrónico. Para obtener más información, vea Supervisión de 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>.

Límites de velocidad actuales

Azure DevOps actualmente tiene un límite de consumo global. Este límite retrasa las solicitudes de usuarios individuales más allá de un umbral cuando los recursos compartidos están en peligro de sobrecarga.

Límite de consumo global

Este límite se centra exclusivamente en evitar interrupciones cuando los recursos compartidos están a punto de sobrecargarse. Normalmente, los usuarios individuales solo tienen sus solicitudes retrasadas cuando se produce una de las siguientes situaciones:

• Uno de sus recursos compartidos corre el riesgo de estar sobrecargado
• Su uso personal supera 200 veces el consumo de un usuario típico en una ventana (deslizante) de cinco minutos.

La cantidad del retraso depende del nivel de consumo constante del usuario. Los retrasos van desde unos 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, los retrasos pueden continuar indefinidamente para proteger el recurso.

Azure DevOps unidades de rendimiento (TSTUs)

Azure DevOps usuarios consumen muchos recursos compartidos y el consumo depende de muchos factores. Por ejemplo:

• 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 una carga de base de datos en función del número de elementos de trabajo que buscan.
• Compila la carga de la unidad descargando archivos desde el control de versiones, generando la salida del registro, y así sucesivamente.
• Todas las operaciones consumen CPU y memoria en varias partes del servicio.

Para dar cabida a todo esto, Azure DevOps consumo de recursos se expresa en unidades abstractas denominadas Azure DevOps de rendimiento o TSTUs.

Las TSTUs finalmente incorporan una combinación de lo siguiente:

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

Por ahora, las TSTUs se centran principalmente en las DTU Azure SQL Database, ya que las bases de datos de Azure SQL son los recursos compartidos que normalmente están sobrecargados por un consumo excesivo.

Una única TSTU es la carga media que se espera que un único usuario normal de Azure DevOps genere cada cinco minutos. Los usuarios normales también generan picos de carga. Estos picos suelen ser 10 o menos TSTUs cada cinco minutos. Con menos frecuencia, los picos van hasta 100 TSTUs. El límite de consumo global es de 200 TSTUs en un plazo deslizante de cinco minutos.

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. Incluso si los agentes de compilación se hospedan automáticamente, generan carga en forma de clonación y envío de registros.

Aplicamos 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 se bloquea por limitación de velocidad, aparece un mensaje en los registros adjuntos.

Experiencia de cliente de API

Cuando las solicitudes se retrasan o se bloquean, Azure DevOps los encabezados de respuesta para ayudar a los clientes de API a reaccionar. Aunque no están totalmente estandarizados, estos encabezados están ampliamente en línea con otros servicios populares.

En la tabla siguiente se enumeran los encabezados disponibles y lo que significan. Excepto para X-RateLimit-Delay , todos 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.