Frequentie- en gebruikslimieten

  • Artikel

Azure DevOps Services

Azure DevOps Services maakt gebruik van meerdere tenants om de kosten te verlagen en de prestaties te verbeteren. Dit ontwerp laat gebruikers kwetsbaar voor prestatieproblemen en zelfs storingen wanneer andere gebruikers van hun gedeelde resources pieken in hun verbruik hebben. Azure DevOps beperkt dus de resources die personen kunnen gebruiken en de hoeveelheid aanvragen die ze kunnen indienen bij bepaalde opdrachten. Wanneer deze limieten worden overschreden, kunnen toekomstige aanvragen worden vertraagd of geblokkeerd.

Zie Git-limieten en aanbevolen procedures voor meer informatie om snelheidslimieten te voorkomen.

Globale verbruikslimiet

Azure DevOps heeft momenteel een wereldwijde verbruikslimiet, waardoor aanvragen van afzonderlijke gebruikers buiten een drempelwaarde worden vertraagd wanneer gedeelde resources gevaar lopen te overbelasten. Deze limiet is uitsluitend gericht op het voorkomen van storingen wanneer gedeelde resources bijna worden overweldigd. Afzonderlijke gebruikers krijgen doorgaans alleen vertraagde aanvragen wanneer een van de volgende incidenten optreedt:

  • Een van hun gedeelde resources loopt het risico om overweldigd te worden
  • Hun persoonlijke gebruik overschrijdt 200 keer het verbruik van een typische gebruiker binnen een (glijdende) periode van vijf minuten

De hoeveelheid vertraging is afhankelijk van het duurzame verbruiksniveau van de gebruiker. Vertragingen variëren van een paar milliseconden per aanvraag tot 30 seconden. Zodra het verbruik naar nul gaat of de resource niet meer wordt overspoeld, worden de vertragingen binnen vijf minuten gestopt. Als het verbruik hoog blijft, kunnen vertragingen voor onbepaalde tijd doorgaan om de resource te beveiligen.

Wanneer een gebruikersaanvraag wordt vertraagd met een aanzienlijk bedrag, ontvangt die gebruiker een e-mail en een waarschuwingsbanner op internet. Voor het buildserviceaccount en anderen zonder e-mailadres krijgen leden van de groep Projectverzameling Beheer istrators het e-mailbericht. Zie Gebruik van bewaking voor meer informatie.

Wanneer aanvragen van een afzonderlijke gebruiker worden geblokkeerd, worden antwoorden met HTTP-code 429 (te veel aanvragen) ontvangen, met een bericht dat lijkt op het volgende bericht:

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

Azure DevOps-doorvoereenheden (TSTU's)

Azure DevOps-gebruikers gebruiken veel gedeelde resources en het verbruik is afhankelijk van de volgende factoren:

  • Als u een groot aantal bestanden uploadt naar versiebeheer, wordt een grote hoeveelheid belasting voor databases en opslagaccounts gemaakt
  • Complexe query's voor het bijhouden van werkitems maken databasebelasting op basis van het aantal werkitems dat ze doorzoeken
  • Hiermee wordt de schijfbelasting gebouwd door bestanden te downloaden van versiebeheer, waardoor logboekuitvoer wordt geproduceerd
  • Alle bewerkingen verbruiken CPU en geheugen op verschillende onderdelen van de service

Azure DevOps-resourceverbruik wordt uitgedrukt in abstracte eenheden met de naam Azure DevOps-doorvoereenheden of TSTU's. TSTU's bevatten uiteindelijk een combinatie van de volgende items:

  • DTU's van Azure SQL Database als een meting van databaseverbruik
  • Toepassingslaag en taakagent CPU, geheugen en I/O als maateenheid voor rekenverbruik
  • Azure Storage-bandbreedte als een meting van het opslagverbruik

Voorlopig zijn TSTU's voornamelijk gericht op DTU's van Azure SQL Database, omdat Azure SQL Databases de gedeelde resources zijn die het meest worden overweldigd door overmatig verbruik. Eén TSTU is de gemiddelde belasting die we verwachten dat één normale gebruiker van Azure DevOps per vijf minuten genereert. Normale gebruikers genereren ook pieken in de belasting. Deze pieken zijn doorgaans 10 of minder TSTU's per vijf minuten. Minder vaak gaan pieken zo hoog als 100 TSTU's.

De globale verbruikslimiet is 200 TSTU's binnen een glijdend venster van vijf minuten.

U wordt aangeraden ten minste op de Retry-After koptekst te reageren. Als u een header in een Retry-After antwoord detecteert, wacht u tot enige tijd is verstreken voordat u een andere aanvraag verzendt. Dit helpt uw clienttoepassing minder afgedwongen vertragingen te ervaren. Houd er rekening mee dat het antwoord 200 is, dus u hoeft geen logica voor opnieuw proberen toe te passen op de aanvraag.

Indien mogelijk raden we u verder aan om te controleren en X-RateLimit-Limit headers te gebruikenX-RateLimit-Remaining. Hierdoor kunt u bij benadering bepalen hoe snel u de vertragingsdrempel bereikt. Uw client kan op intelligente wijze reageren en de aanvragen in de loop van de tijd verspreiden.

Notitie

Identiteiten die door hulpprogramma's en toepassingen worden gebruikt om te integreren met Azure DevOps, hebben mogelijk hogere frequentie- en gebruikslimieten nodig dan de toegestane verbruikslimiet van tijd tot tijd. U kunt extra frequentie- en gebruikslimieten krijgen door het toegangsniveau Basic + Test Plans toe te wijzen aan de gewenste identiteiten die door uw toepassing worden gebruikt. Zodra aan de behoefte aan hogere frequentielimieten is voldaan, kunt u teruggaan naar het toegangsniveau dat door de identiteit is gebruikt. Er worden alleen kosten in rekening gebracht voor het toegangsniveau Basic + Test Plans voor de tijd die aan de identiteit is toegewezen.

Identiteiten waaraan al een Visual Studio Enterprise-abonnement is toegewezen, kunnen pas toegangsniveau Basic + Test Plans worden toegewezen nadat ze zijn verwijderd.

Pijplijnen

Snelheidsbeperking is vergelijkbaar voor Azure Pipelines. Elke pijplijn wordt behandeld als een afzonderlijke entiteit met een eigen resourceverbruik bijgehouden. Zelfs als build-agents zelf-hostend zijn, genereren ze belasting in de vorm van het klonen en verzenden van logboeken.

We passen een limiet van 200 TSTU toe voor een afzonderlijke pijplijn in een tijdvenster van 5 minuten. Deze limiet is hetzelfde als de algemene verbruikslimiet voor gebruikers. Als een pijplijn wordt vertraagd of geblokkeerd door snelheidsbeperking, wordt er een bericht weergegeven in de bijgevoegde logboeken.

API-clientervaring

Wanneer aanvragen worden vertraagd of geblokkeerd, retourneert Azure DevOps antwoordheaders om API-clients te helpen reageren. Hoewel deze headers niet volledig zijn gestandaardiseerd, zijn deze headers breed in overeenstemming met andere populaire services.

De volgende tabel bevat de beschikbare headers en wat ze betekenen. X-RateLimit-DelayBehalve, worden al deze headers verzonden voordat aanvragen worden vertraagd. Dit ontwerp biedt clients de mogelijkheid om proactief hun frequentie van aanvragen te vertragen.

Koptekstnaam

Beschrijving

Retry-After

De opgegeven RFC 6585-header geeft aan hoe lang u moet wachten voordat u de volgende aanvraag verzendt om onder de detectiedrempel te vallen. Eenheden: seconden.

X-RateLimit-Resource

Een aangepaste header die de service en het type drempelwaarde aangeeft dat is bereikt. Drempelwaardetypen en servicenamen kunnen in de loop van de tijd variëren en zonder waarschuwing. We raden u aan deze tekenreeks weer te geven aan een mens, maar niet te vertrouwen op de tekenreeks voor berekeningen.

X-RateLimit-Delay

Hoe lang de aanvraag is vertraagd. Eenheden: seconden met maximaal drie decimalen (milliseconden).

X-RateLimit-Limit

Het totale aantal toegestane TSTU's voordat vertragingen worden opgelegd.

X-RateLimit-Remaining

Het aantal resterende TSTU's voordat deze wordt vertraagd. Als aanvragen al worden vertraagd of geblokkeerd, is dit 0.

X-RateLimit-Reset

Wanneer het gebruik van alle resources onmiddellijk is gestopt, wordt het bijgehouden gebruik teruggezet naar 0 TSTU's. Uitgedrukt in Unix epoch time.

Werktracking, proces- en projectlimieten

Azure DevOps legt limieten op voor het aantal projecten dat u in een organisatie kunt hebben en het aantal teams dat u binnen elk project kunt hebben. Houd ook rekening met limieten voor werkitems, query's, achterstanden, borden, dashboards en meer. Zie Werktracking, proces- en projectlimieten voor meer informatie.

Wiki

Naast de gebruikelijke limieten voor opslagplaatsen zijn wiki's die voor een project zijn gedefinieerd, beperkt tot 25 MB per bestand.

Serviceverbindingen

Er gelden geen limieten per project voor het maken van serviceverbindingen. Er kunnen echter limieten zijn, die worden opgelegd via Microsoft Entra-id. Raadpleeg de volgende artikelen voor meer informatie: