Partager via

Limites de taux et d’utilisation

  • Article

Azure DevOps Services

Azure DevOps Services utilise l’architecture mutualisée pour réduire les coûts et améliorer les performances. Cette conception laisse les utilisateurs vulnérables aux problèmes de performances et même aux pannes lorsque d’autres utilisateurs de leurs ressources partagées ont des pics de consommation. Par conséquent, Azure DevOps limite les ressources que les utilisateurs peuvent consommer et la quantité de demandes qu’ils peuvent effectuer à certaines commandes. Lorsque ces limites sont dépassées, les futures demandes peuvent être retardées ou bloquées.

Pour plus d’informations, consultez les limites git et les meilleures pratiques pour éviter d’atteindre les limites de taux.

Limite de consommation globale

Azure DevOps a actuellement une limite de consommation globale, ce qui retarde les demandes d’utilisateurs individuels au-delà d’un seuil lorsque les ressources partagées risquent d’être submergées. Cette limite est axée exclusivement sur l’évitement des pannes lorsque les ressources partagées sont proches d’être submergées. Les utilisateurs individuels reçoivent généralement uniquement des demandes retardées quand l’un des incidents suivants se produit :

  • L’une de leurs ressources partagées risque d’être submergée
  • Leur utilisation personnelle dépasse 200 fois la consommation d’un utilisateur classique dans une fenêtre (glissante) cinq minutes

Le délai dépend du niveau de consommation soutenu de l’utilisateur. Les retards vont de quelques millisecondes par requête jusqu’à 30 secondes. Une fois que la consommation passe à zéro ou que la ressource n’est plus submergée, les retards s’arrêtent dans les cinq minutes. Si la consommation reste élevée, les retards peuvent continuer indéfiniment à protéger la ressource.

Lorsqu’une demande d’utilisateur est retardée d’une quantité importante, cet utilisateur reçoit un e-mail et une bannière d’avertissement sur le web. Pour le compte de service de génération et d’autres personnes sans adresse e-mail, les membres du groupe Collection de projets Administration istrators obtiennent l’e-mail. Pour plus d’informations, consultez Supervision de l’utilisation.

Lorsque les requêtes d’un utilisateur individuel sont bloquées, les réponses avec le code HTTP 429 (trop de requêtes) sont reçues, avec un message similaire au message suivant :

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

Unités de débit Azure DevOps (TSTUs)

Les utilisateurs d’Azure DevOps consomment de nombreuses ressources partagées et la consommation dépend des facteurs suivants :

  • Le chargement d’un grand nombre de fichiers dans le contrôle de version crée une grande quantité de charge sur les bases de données et les comptes de stockage
  • Les requêtes de suivi d’éléments de travail complexes créent une charge de base de données en fonction du nombre d’éléments de travail qu’ils recherchent via
  • Génère une charge de lecteur en téléchargeant des fichiers à partir du contrôle de version, en produisant une sortie de journal
  • Toutes les opérations consomment du processeur et de la mémoire sur différentes parties du service

Pour prendre en charge, la consommation de ressources Azure DevOps est exprimée en unités abstraites appelées unités de débit Azure DevOps ou TSTUs. Les TSTU incorporent finalement un mélange des éléments suivants :

  • DTU Azure SQL Database comme mesure de la consommation de base de données
  • Processeur, mémoire et E/S du niveau application et agent de travail comme mesure de la consommation de calcul
  • Stockage Azure bande passante comme mesure de la consommation de stockage

Pour l’instant, les TSTU se concentrent principalement sur les DTU Azure SQL Database, car les bases de données Azure SQL sont les ressources partagées les plus souvent submergées par une consommation excessive. Une seule TSTU est la charge moyenne que nous attendons d’un seul utilisateur normal d’Azure DevOps à générer toutes les cinq minutes. Les utilisateurs normaux génèrent également des pics de charge. Ces pics sont généralement de 10 ou moins TSTUS par cinq minutes. Moins fréquemment, les pics vont aussi haut que 100 TSTUS.

La limite de consommation globale est de 200 TSTUS dans une fenêtre glissante de cinq minutes.

Nous vous recommandons au moins de répondre à l’en-tête Retry-After . Si vous détectez un Retry-After en-tête dans une réponse, attendez un certain temps avant d’envoyer une autre demande. Cela permet à votre application cliente d’avoir moins de retards appliqués. N’oubliez pas que la réponse est 200. Vous n’avez donc pas besoin d’appliquer la logique de nouvelle tentative à la requête.

Si possible, nous vous recommandons également de surveiller X-RateLimit-Remaining et X-RateLimit-Limit d’en-têtes. Cela vous permet d’estimer la rapidité avec laquelle vous approchez du seuil de retard. Votre client peut réagir intelligemment et répartir ses demandes au fil du temps.

Remarque

Les identités utilisées par les outils et les applications pour s’intégrer à Azure DevOps peuvent nécessiter des limites de débit et d’utilisation plus élevées au-delà de la limite de consommation autorisée de temps en temps. Vous pouvez obtenir des limites de taux et d’utilisation supplémentaires en attribuant le niveau d’accès De Base + Plans de test aux identités souhaitées utilisées par votre application. Une fois que le besoin de limites de taux plus élevées est satisfait, vous pouvez revenir au niveau d’accès que l’identité utilisait initialement. Vous êtes facturé pour le coût de niveau d’accès De base + Plans de test uniquement pour le moment où il est affecté à l’identité.

Les identités déjà affectées à un abonnement Visual Studio Enterprise ne peuvent pas être affectées au niveau d’accès De base + Plans de test jusqu’à ce qu’elles soient supprimées.

Pipelines

La limitation du débit est similaire pour Azure Pipelines. Chaque pipeline est traité comme une entité individuelle avec son propre suivi de la consommation de ressources. Même si les agents de build sont auto-hébergés, ils génèrent une charge sous la forme de clonage et d’envoi de journaux.

Nous appliquons une limite de 200 TSTU pour un pipeline individuel dans une fenêtre glissante de 5 minutes. Cette limite est identique à la limite de consommation globale pour les utilisateurs. Si un pipeline est retardé ou bloqué par une limitation de débit, un message apparaît dans les journaux attachés.

Expérience client de l’API

Lorsque les demandes sont retardées ou bloquées, Azure DevOps retourne des en-têtes de réponse pour aider les clients d’API à réagir. Bien qu’ils ne soient pas entièrement normalisés, ces en-têtes sont largement conformes à d’autres services populaires.

Le tableau suivant répertorie les en-têtes disponibles et ce qu’ils signifient. X-RateLimit-DelayÀ l’exception de , tous ces en-têtes sont envoyés avant que les demandes ne commencent à être retardées. Cette conception donne aux clients la possibilité de ralentir de manière proactive leur taux de demandes.

Nom de l’en-tête

Description

Retry-After

L’en-tête spécifié RFC 6585 envoyé pour vous indiquer le temps d’attente avant d’envoyer votre requête suivante pour tomber sous le seuil de détection. Unités : secondes.

X-RateLimit-Resource

En-tête personnalisé indiquant le service et le type de seuil atteint. Les types de seuil et les noms de service peuvent varier au fil du temps et sans avertissement. Nous vous recommandons d’afficher cette chaîne sur un humain, mais pas de l’utiliser pour le calcul.

X-RateLimit-Delay

Combien de temps la demande a été retardée. Unités : secondes avec jusqu’à trois décimales (millisecondes).

X-RateLimit-Limit

Nombre total de TSTUS autorisées avant l’imposer.

X-RateLimit-Remaining

Nombre de TSTUS restants avant d’être retardés. Si les demandes sont déjà retardées ou bloquées, il s’agit de 0.

X-RateLimit-Reset

Heure à laquelle, si toute la consommation de ressources s’est arrêtée immédiatement, l’utilisation suivie revient à 0 TSTU. Exprimé dans l’époque Unix.

Suivi du travail, processus et limites de projet

Azure DevOps impose des limites pour le nombre de projets que vous pouvez avoir dans une organisation et le nombre d’équipes que vous pouvez avoir au sein de chaque projet. Tenez également compte des limites des éléments de travail, des requêtes, des backlogs, des tableaux de bord, etc. Pour plus d’informations, consultez Suivi du travail, processus et limites du projet.

Wiki

Outre les limites de référentiel habituelles, les wikis définis pour un projet sont limités à 25 Mo par fichier unique.

Connexions de service

Aucune limite par projet n’est appliquée à la création de connexions de service. Toutefois, il peut y avoir des limites qui sont imposées via l’ID Microsoft Entra. Pour plus d’informations, consultez les articles suivants :