Delen via

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 voor meer informatie Git-limieten en Aanbevolen procedures 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 ontvangen leden van de groep Projectverzamelingsbeheerders de e-mail. Zie Gebruik monitoring 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

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
  • De schijfbelasting wordt verhoogd door bestanden te downloaden van versiebeheer en loguitvoer te produceren.
  • Alle bewerkingen verbruiken CPU en geheugen op verschillende onderdelen van de service

Om tegemoet te komen aan dit, wordt het Azure DevOps-resourceverbruik uitgedrukt in abstracte eenheden die Azure DevOps-doorvoereenheden (TSTU's) worden genoemd. TSTU's bevatten uiteindelijk een combinatie van de volgende items:

  • Azure SQL Database DTU's als 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 van een typische gebruiker van Azure DevOps om per vijf minuten te genereren. Typische 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 te reageren op de Retry-After header. Als u een Retry-After header in een antwoord detecteert, wacht enige tijd voordat u een nieuw verzoek verzendt. Dit helpt uw klantapplicatie om met minder afgedwongen vertragingen te maken te hebben. 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 aan om X-RateLimit-Remaining en X-RateLimit-Limit headers te bewaken. 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 soms hogere frequentie- en gebruikslimieten nodig dan de toegestane verbruikslimiet. U kunt deze limieten verhogen door de Basic + Test Plans toegangsniveau toe te wijzen aan de gewenste identiteiten die door uw toepassing worden gebruikt. Zodra aan de behoefte aan hogere frequentielimieten is voldaan, kunt u terugkeren naar het vorige toegangsniveau. Er worden alleen kosten in rekening gebracht voor het Basic + Test Plans toegangsniveau gedurende de periode die aan de identiteit is toegewezen.

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

Pijpleidingen

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 TSTU-limiet van 200 toe voor een afzonderlijke pijplijn in een glijdend tijdsvenster 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, worden deze headers breed in overeenstemming met andere populaire services.

De volgende tabel bevat de beschikbare headers en wat ze betekenen. Met uitzondering van X-RateLimit-Delayworden 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 RFC 6585-opgegeven header informeert u over hoelang u moet wachten voordat u uw volgende verzoek verzendt om onder de detectiedrempel te blijven. 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 TSTUs dat is toegestaan voordat vertragingen worden opgelegd.

X-RateLimit-Remaining

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

X-RateLimit-Reset

Het tijdstip waarop, als het gebruik van alle resources onmiddellijk zou stoppen, het bijgehouden gebruik zou terugkeren 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 zijn gedefinieerd voor een project 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: