Partager via

Limites de débit et d’utilisation

Azure DevOps Services

Azure DevOps Services utilise l’architecture mutualisée pour réduire les coûts et améliorer les performances. Cette conception peut entraîner des problèmes de performances ou des pannes lorsque d’autres utilisateurs de ressources partagées ont des pics de consommation. Pour éviter cela, Azure DevOps limite les ressources que chaque utilisateur peut consommer et le nombre de demandes qu’il peut effectuer à certaines commandes. Si vous dépassez ces limites, les futures demandes peuvent être retardées ou bloquées.

Apprenez-en davantage sur les limites git et les meilleures pratiques pour éviter d’atteindre les limites de débit.

Limite de consommation globale

Azure DevOps a une limite de consommation globale qui retarde les demandes des utilisateurs individuels lorsque les ressources partagées risquent d’être submergées. Cette limite permet d’éviter les pannes lorsque les ressources partagées sont proches d’être submergées. Les utilisateurs individuels rencontrent généralement des demandes retardées uniquement lorsque 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 typique sur une période glissante de 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. Lorsque la consommation passe à zéro ou que la ressource n’est pas 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, l’utilisateur reçoit un e-mail et une bannière d’avertissement sur le web. Pour le compte de service de compilation et d’autres sans adresse e-mail, les membres du groupe Administrateurs de la collection de projets reçoivent l’e-mail. Pour plus d’informations, consultez Supervision de l’utilisation.

Quand les requêtes d’un utilisateur individuel sont bloquées, l’utilisateur reçoit des réponses avec le code HTTP 429 (trop de requêtes) et un message similaire à ce qui suit :

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

Les utilisateurs d’Azure DevOps consomment de nombreuses ressources partagées, et le niveau de consommation dépend de facteurs tels que :

  • Le chargement d'un grand nombre de fichiers dans le système de gestion de versions augmente la charge sur les bases de données et les comptes de stockage.
  • Exécution de requêtes complexes d’éléments de travail, ce qui augmente la charge de la base de données en fonction du nombre d’éléments de travail recherchés.
  • Exécution des builds, qui téléchargent des fichiers à partir du système de contrôle de version et produisent un journal de sortie.
  • Opérations générales, qui consomment le processeur et la mémoire dans différentes parties du service.

Pour mesurer cette activité, Azure DevOps exprime la consommation de ressources dans les unités de débit Azure DevOps (TSTUs) . Un TSTU est une unité de charge abstraite qui représente un mélange de ressources différentes, notamment :

  • Utilisation de la base de données , mesurée principalement via des DTU Azure SQL Database.
  • Utilisation du calcul : processeur, mémoire et E/S à partir des niveaux d’application et des agents de travail.
  • Utilisation du stockage : bande passante stockage Azure.

Remarque

Les TSTU sont intentionnellement abstraites. Ils agrègent la consommation des ressources entre les couches de calcul, de stockage et de base de données au sein d’une infrastructure distribuée. Les métriques sous-jacentes (PROCESSEUR, mémoire, E/S, DTU) ne sont pas directement exposées ou significatives. Les TSTU offrent un moyen unifié de représenter la charge, ce qui facilite la gestion et la surveillance de l’utilisation sans exposer la complexité totale des composants de ressources individuels. Vous ne pouvez pas calculer l'utilisation en TSTUs pour une action à l'aide d'une formule, mais vous pouvez voir le nombre de TSTUs qu'une opération consomme sur la page surveillance de l'usage. Certaines opérations, telles que les requêtes d’éléments de travail, varient en consommation à mesure que votre organisation croît et évolue, de sorte que vous devrez peut-être évaluer périodiquement pour garantir l'exactitude.

Actuellement, les TSTU se concentrent principalement sur les DTU Azure SQL Database, car les bases de données sont la ressource partagée la plus susceptible d’être submergée par une consommation excessive.

  • Un TSTU représente la charge moyenne générée par un utilisateur Azure DevOps classique sur cinq minutes.
  • L’activité utilisateur normale peut générer des pics de 10 TSTUS ou moins par cinq minutes.
  • Les pics plus grands mais moins fréquents peuvent atteindre jusqu’à 100 TSTUS.
  • La limite globale est de 200 TSTUs dans une fenêtre glissante de cinq minutes.

Meilleures pratiques

  • Respectez l’en-tête Retry-After : si vous le recevez dans une réponse, attendez l’heure spécifiée avant d’envoyer une autre requête. La réponse retourne toujours HTTP 200. Par conséquent, la logique de nouvelle tentative n’est pas nécessaire.
  • Surveiller les en-têtes X-RateLimit : s'ils sont disponibles, suivez X-RateLimit-Remaining et X-RateLimit-Limit pour estimer approximativement la rapidité avec laquelle vous approchez du seuil. Cela permet à votre client d'atténuer les rafales de demandes et d’éviter les retards imposés.

Remarque

Les identités utilisées par les outils et les applications pour s’intégrer à Azure DevOps peuvent parfois nécessiter des limites de débit et d’utilisation plus élevées au-delà de la limite de consommation autorisée. Augmentez ces limites en affectant le niveau d’accès Basic + Test Plans aux identités que votre application utilise. Une fois que vous n’avez plus besoin de limites de débit plus élevées, revenez au niveau d’accès précédent. Vous êtes facturé pour le niveau d’accès De base + Plans de test uniquement pour la durée affectée à 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 Basic + Test Plans tant que vous n’avez pas supprimé l’abonnement.

Conduites

La limitation de débit fonctionne de la même façon pour Azure Pipelines. Chaque pipeline est une entité individuelle et sa consommation de ressources est suivie séparément. Même si les agents de build sont auto-hébergés, ils génèrent une charge en clonant et en envoyant des journaux.

Il existe une limite de 200 TSTU pour chaque pipeline dans une fenêtre glissante de 5 minutes. Cette limite correspond à la limite de consommation globale pour les utilisateurs. Si la limitation de débit retarde ou bloque un pipeline, un message s’affiche dans les journaux associé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. À l’exception de X-RateLimit-Delay, tous ces en-têtes sont envoyés avant que les demandes ne commencent à être retardées. Cette conception permet aux clients de ralentir de manière proactive leur taux de demandes.

nom d’en-tête

Description

Retry-After

L’en-tête spécifié par RFC 6585 est envoyé pour vous indiquer combien de temps attendre avant d’envoyer votre prochaine requête, afin de ne pas dépasser 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 à une personne, mais de ne pas compter sur elle pour des calculs.

X-RateLimit-Delay

Durée pendant laquelle la demande est retardée. Unités : secondes avec jusqu’à trois décimales (millisecondes).

X-RateLimit-Limit

Nombre total de TSTU autorisés avant que des retards ne soient imposés.

X-RateLimit-Remaining

Nombre de TSTUS restant avant le début des retards. Si les demandes sont déjà retardées ou bloquées, il s’agit de 0.

X-RateLimit-Reset

Heure à laquelle, si toutes les consommations de ressources s’arrêtent immédiatement, l’utilisation suivie retourne à 0 TSTUS. Exprimé en heure epoch Unix.

Suivi du travail, processus et limites de projet

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

Site collaboratif Wiki

En plus des limites de référentiel habituelles, un fichier wiki dans un projet peut atteindre jusqu’à 25 Mo.

Connexions de service

Il n’existe aucune limite par projet pour la création de connexions de service. Toutefois, les limites peuvent être imposées via l’ID Microsoft Entra. Pour plus d’informations, consultez les articles suivants :

Contenu connexe

  • Last updated on