Dela via

Hastighets- och användningsgränser

  • Artikel

Azure DevOps Services

Azure DevOps Services använder flera innehavare för att minska kostnaderna och förbättra prestandan. Den här designen gör användarna sårbara för prestandaproblem och till och med avbrott när andra användare av deras delade resurser har toppar i sin förbrukning. Azure DevOps begränsar därför de resurser som enskilda användare kan använda och hur många begäranden de kan göra till vissa kommandon. När dessa gränser överskrids kan framtida begäranden antingen fördröjas eller blockeras.

Mer information finns i Git-gränser och metodtips för att undvika att nå hastighetsgränser.

Global förbrukningsgräns

Azure DevOps har för närvarande en global förbrukningsgräns som fördröjer begäranden från enskilda användare över ett tröskelvärde när delade resurser riskerar att överbelastas. Den här gränsen fokuserar enbart på att undvika avbrott när delade resurser är nära att överbelastas. Enskilda användare får vanligtvis bara fördröjda begäranden när någon av följande incidenter inträffar:

  • En av deras delade resurser riskerar att bli överbelastad
  • Deras personliga användning överskrider 200 gånger förbrukningen för en typisk användare inom ett (glidande) femminutersfönster

Fördröjningen beror på användarens varaktiga förbrukningsnivå. Fördröjningar varierar från några millisekunder per begäran upp till 30 sekunder. När förbrukningen är noll eller resursen inte längre överbelastas stoppas fördröjningarna inom fem minuter. Om förbrukningen förblir hög kan fördröjningar fortsätta på obestämd tid för att skydda resursen.

När en användarbegäran fördröjs med en betydande mängd får användaren ett e-postmeddelande och en varningsbanderoll på webben. För byggtjänstkontot och andra utan en e-postadress får medlemmar i gruppen Administratörer för projektsamling e-postmeddelandet. Mer information finns i Användningsövervakning.

När en enskild användares begäranden blockeras tas svar med HTTP-kod 429 (för många begäranden) emot med ett meddelande som liknar följande meddelande:

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

Azure DevOps-dataflödesenheter (TSTU:er)

Azure DevOps-användare använder många delade resurser och förbrukningen beror på följande faktorer:

  • Om du laddar upp ett stort antal filer till versionskontrollen skapas en stor belastning på databaser och lagringskonton
  • Komplexa frågor för spårning av arbetsobjekt skapar databasbelastning baserat på antalet arbetsobjekt som de söker igenom
  • Skapar enhetsbelastning genom att ladda ned filer från versionskontroll, skapa loggutdata
  • Alla åtgärder förbrukar cpu och minne på olika delar av tjänsten

För att hantera detta uttrycks Azure DevOps-resursförbrukning i abstrakta enheter som kallas Azure DevOps-dataflödesenheter eller TSTU:er. TSTU:er innehåller så småningom en blandning av följande objekt:

  • Azure SQL Database DTU:er som ett mått på databasförbrukning
  • Processor, minne och I/O för programnivå och jobbagent som ett mått på beräkningsförbrukningen
  • Azure Storage-bandbredd som ett mått på lagringsförbrukning

För närvarande fokuserar TSTU:er främst på Azure SQL Database DTU:er, eftersom Azure SQL Database är de delade resurser som oftast överbelastas av överdriven förbrukning. En enskild TSTU är den genomsnittliga belastning som vi förväntar oss att en enskild normal användare av Azure DevOps ska generera per fem minuter. Normala användare genererar också toppar i belastningen. Dessa toppar är vanligtvis 10 eller färre TSTU:er per fem minuter. Mindre ofta går toppar så högt som 100 TSTU:er.

Den globala förbrukningsgränsen är 200 TSTU:er inom ett glidande femminutersfönster.

Vi rekommenderar att du åtminstone svarar på Retry-After rubriken. Om du identifierar en Retry-After rubrik i något svar väntar du tills en viss tid har passerat innan du skickar en annan begäran. Det gör att klientprogrammet får färre fördröjningar. Tänk på att svaret är 200, så du behöver inte tillämpa logik för återförsök på begäran.

Om möjligt rekommenderar vi ytterligare att du övervakar X-RateLimit-Remaining och X-RateLimit-Limit rubriker. På så sätt kan du uppskatta hur snabbt du närmar dig tröskelvärdet för fördröjning. Klienten kan reagera intelligent och sprida ut sina begäranden över tid.

Kommentar

Identiteter som används av verktyg och program för att integrera med Azure DevOps kan behöva högre hastighets- och användningsgränser utöver den tillåtna förbrukningsgränsen då och då. Du kan få ytterligare pris- och användningsgränser genom att tilldela åtkomstnivån Grundläggande + Testplaner till önskade identiteter som används av ditt program När behovet av högre hastighetsgränser har uppfyllts kan du gå tillbaka till den åtkomstnivå som identiteten brukade ha. Du debiteras endast för kostnaden för åtkomstnivån Grundläggande + Testplaner för den tid som den tilldelas till identiteten.

Identiteter som redan har tilldelats en Visual Studio Enterprise-prenumeration kan inte tilldelas åtkomstnivån Grundläggande + Testplaner förrän de har tagits bort.

Pipelines

Hastighetsbegränsningen är liknande för Azure Pipelines. Varje pipeline behandlas som en enskild entitet med en egen resursförbrukning spårad. Även om kompileringsagenter är lokalt installerade genererar de belastning i form av kloning och sändning av loggar.

Vi tillämpar en gräns på 200 TSTU för en enskild pipeline i ett glidande 5-minutersfönster. Den här gränsen är densamma som den globala förbrukningsgränsen för användare. Om en pipeline fördröjs eller blockeras av hastighetsbegränsning visas ett meddelande i de bifogade loggarna.

API-klientupplevelse

När begäranden fördröjs eller blockeras returnerar Azure DevOps svarshuvuden för att hjälpa API-klienter att reagera. Även om de inte är helt standardiserade är dessa rubriker i stort sett i linje med andra populära tjänster.

I följande tabell visas de tillgängliga rubrikerna och vad de betyder. X-RateLimit-DelayFörutom skickas alla dessa huvuden innan begäranden börjar bli försenade. Den här designen ger klienterna möjlighet att proaktivt sakta ned antalet begäranden.

Rubriknamn

Beskrivning

Retry-After

Det RFC 6585-angivna huvudet har skickats för att berätta hur lång tid du ska vänta innan du skickar nästa begäran om att hamna under tröskelvärdet för identifiering. Enheter: sekunder.

X-RateLimit-Resource

En anpassad rubrik som anger den tjänst och typ av tröskelvärde som uppnåddes. Tröskelvärdestyper och tjänstnamn kan variera över tid och utan varning. Vi rekommenderar att du visar den här strängen för en människa, men inte förlitar sig på den för beräkning.

X-RateLimit-Delay

Hur länge begäran försenades. Enheter: sekunder med upp till tre decimaler (millisekunder).

X-RateLimit-Limit

Totalt antal TSTU:er som tillåts innan fördröjningar införs.

X-RateLimit-Remaining

Antal TSTU:er som återstår innan de fördröjs. Om begäranden redan fördröjs eller blockeras är det 0.

X-RateLimit-Reset

När all resursförbrukning stoppades omedelbart skulle spårad användning återgå till 0 TSTU:er. Uttryckt i Unix epoktid.

Arbetsspårning, process- och projektgränser

Azure DevOps begränsar antalet projekt som du kan ha i en organisation och antalet team som du kan ha i varje projekt. Tänk också på begränsningar för arbetsobjekt, frågor, kvarvarande uppgifter, tavlor, instrumentpaneler med mera. Mer information finns i Arbetsspårning, process- och projektgränser.

Wiki

Förutom de vanliga lagringsplatsens gränser är wikis som definierats för ett projekt begränsade till 25 MB per enskild fil.

Tjänstanslutningar

Det finns inga gränser per projekt för att skapa tjänstanslutningar. Det kan dock finnas gränser som införs via Microsoft Entra-ID. Mer information finns i följande artiklar: