Limites de taxa e uso

  • Artigo

Azure DevOps Services

Os Serviços de DevOps do Azure usam multilocação para reduzir custos e melhorar o desempenho. Esse design deixa os usuários vulneráveis a problemas de desempenho e até mesmo interrupções quando outros usuários de seus recursos compartilhados têm picos em seu consumo. Portanto, o Azure DevOps limita os recursos que os indivíduos podem consumir e a quantidade de solicitações que eles podem fazer a determinados comandos. Quando esses limites são excedidos, solicitações futuras podem ser atrasadas ou bloqueadas.

Para obter mais informações, consulte Limites do Git e Práticas recomendadas para evitar atingir limites de taxa.

Limite de consumo global

Atualmente, o Azure DevOps tem um limite de consumo global, que atrasa solicitações de usuários individuais além de um limite quando os recursos compartilhados correm o risco de serem sobrecarregados. Esse limite é focado exclusivamente em evitar interrupções quando os recursos compartilhados estão perto de serem sobrecarregados. Os usuários individuais normalmente só recebem solicitações atrasadas quando ocorre um dos seguintes incidentes:

  • Um de seus recursos compartilhados corre o risco de ficar sobrecarregado
  • Seu uso pessoal excede 200 vezes o consumo de um usuário típico dentro de uma janela (deslizante) de cinco minutos

O valor do atraso depende do nível sustentado de consumo do usuário. Os atrasos variam de alguns milissegundos por solicitação até 30 segundos. Quando o consumo chega a zero ou o recurso não está mais sobrecarregado, os atrasos param em cinco minutos. Se o consumo permanecer alto, os atrasos podem continuar indefinidamente para proteger o recurso.

Quando uma solicitação de usuário é atrasada em uma quantidade significativa, esse usuário recebe um e-mail e um banner de aviso na Web. Para a conta de serviço de compilação e outras sem um endereço de email, os membros do grupo Administradores de Coleção de Projetos recebem o email. Para mais informações, veja Monitoramento de uso.

Quando as solicitações de um usuário individual são bloqueadas, as respostas com o código HTTP 429 (muitas solicitações) são recebidas, com uma mensagem semelhante à seguinte mensagem:

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

Unidades de taxa de transferência (TSTUs) do Azure DevOps

Os usuários do Azure DevOps consomem muitos recursos compartilhados e o consumo depende dos seguintes fatores:

  • O carregamento de um grande número de arquivos para o controle de versão cria uma grande quantidade de carga em bancos de dados e contas de armazenamento
  • Consultas complexas de controle de item de trabalho criam carga de banco de dados com base no número de itens de trabalho pesquisados
  • Cria a carga da unidade baixando arquivos do controle de versão, produzindo saída de log
  • Todas as operações consomem CPU e memória em várias partes do serviço

Para acomodar, o consumo de recursos do Azure DevOps é expresso em unidades abstratas chamadas unidades de taxa de transferência do Azure DevOps ou TSTUs. Os TSTUs eventualmente incorporam uma mistura dos seguintes itens:

  • DTUs do Banco de Dados SQL do Azure como uma medida do consumo do banco de dados
  • CPU, memória e E/S da camada de aplicativo e do agente de trabalho como medida do consumo de computação
  • Largura de banda do Armazenamento do Azure como uma medida do consumo de armazenamento

Por enquanto, os TSTUs estão focados principalmente nas DTUs do Banco de Dados SQL do Azure, já que os Bancos de Dados SQL do Azure são os recursos compartilhados mais comumente sobrecarregados pelo consumo excessivo. Um único TSTU é a carga média que esperamos que um único usuário normal do Azure DevOps gere por cinco minutos. Usuários normais também geram picos de carga. Esses picos são tipicamente 10 ou menos TSTUs por cinco minutos. Menos frequentemente, os picos chegam a 100 TSTUs.

O limite de consumo global é de 200 TSTUs em uma janela deslizante de cinco minutos.

Recomendamos que você pelo menos responda ao Retry-After cabeçalho. Se você detectar um Retry-After cabeçalho em qualquer resposta, aguarde até que algum tempo passe antes de enviar outra solicitação. Isso ajuda seu aplicativo cliente a experimentar menos atrasos forçados. Lembre-se de que a resposta é 200, portanto, você não precisa aplicar lógica de repetição à solicitação.

Se possível, recomendamos ainda que você monitore X-RateLimit-Remaining e X-RateLimit-Limit cabeçalhos. Isso permite que você se aproxime da rapidez com que está se aproximando do limite de atraso. Seu cliente pode reagir de forma inteligente e espalhar suas solicitações ao longo do tempo.

Observação

As identidades usadas por ferramentas e aplicativos para integração com o Azure DevOps podem precisar de limites de taxa e uso mais altos além do limite de consumo permitido de tempos em tempos. Você pode obter limites adicionais de taxa e uso atribuindo o nível de acesso Básico + Planos de Teste às identidades desejadas usadas pelo seu aplicativo. Depois que a necessidade de limites de taxa mais altos for atendida, você poderá voltar ao nível de acesso que a identidade costumava ter. Você será cobrado pelo custo do nível de acesso Básico + Planos de Teste somente pelo tempo em que for atribuído à identidade.

As identidades que já receberam uma assinatura do Visual Studio Enterprise não podem receber o nível de acesso Básico + Planos de Teste até que sejam removidas.

Pipelines

O limite de taxa é semelhante para o Azure Pipelines. Cada pipeline é tratado como uma entidade individual com seu próprio consumo de recursos rastreado. Mesmo que os agentes de build sejam auto-hospedados, eles geram carga na forma de clonagem e envio de logs.

Aplicamos um limite de 200 TSTU para um pipeline individual em uma janela deslizante de 5 minutos. Esse limite é o mesmo que o limite de consumo global para os usuários. Se um pipeline for atrasado ou bloqueado por limitação de taxa, uma mensagem será exibida nos logs anexados.

Experiência do cliente de API

Quando as solicitações são atrasadas ou bloqueadas, o Azure DevOps retorna cabeçalhos de resposta para ajudar os clientes de API a reagir. Embora não sejam totalmente padronizados, esses cabeçalhos estão amplamente alinhados com outros serviços populares.

A tabela a seguir lista os cabeçalhos disponíveis e o que eles significam. Com exceção X-RateLimit-Delaydo , todos esses cabeçalhos são enviados antes que as solicitações comecem a ser atrasadas. Esse design dá aos clientes a oportunidade de diminuir proativamente sua taxa de solicitações.

Nome do cabeçalho

Descrição

Retry-After

O cabeçalho especificado pela RFC 6585 foi enviado para informar quanto tempo esperar antes de enviar sua próxima solicitação para se enquadrar no limite de detecção. Unidades: segundos.

X-RateLimit-Resource

Um cabeçalho personalizado indicando o serviço e o tipo de limite que foi atingido. Os tipos de limite e os nomes de serviço podem variar ao longo do tempo e sem aviso. Recomendamos exibir essa cadeia de caracteres para um humano, mas não depender dela para computação.

X-RateLimit-Delay

Quanto tempo o pedido atrasou. Unidades: segundos com até três casas decimais (milissegundos).

X-RateLimit-Limit

Número total de TSTU permitidos antes da imposição de atrasos.

X-RateLimit-Remaining

Número de TSTUs restantes antes de serem adiadas. Se as solicitações já estiverem sendo atrasadas ou bloqueadas, é 0.

X-RateLimit-Reset

Tempo em que, se todo o consumo de recursos parasse imediatamente, o uso rastreado retornaria a 0 TSTUs. Expresso em tempo de época Unix.

Acompanhamento de trabalho, processo, limites do projeto

O Azure DevOps impõe limites para o número de projetos que você pode ter em uma organização e o número de equipes que você pode ter em cada projeto. Também esteja ciente dos limites para itens de trabalho, consultas, listas de pendências, quadros, painéis e muito mais. Para obter mais informações, consulte Acompanhamento de trabalho, processo e limites de projeto.

Wiki

Além dos limites usuais de repositório, os wikis definidos para um projeto são limitados a 25 MB por único arquivo.

Conexões de serviço

Não há limites por projeto colocados na criação de conexões de serviço. No entanto, pode haver limites, que são impostos por meio do Microsoft Entra ID. Para obter informações adicionais, examine os seguintes artigos: