Megosztás a következőn keresztül:

Rate and usage limits

  • Cikk

Azure DevOps Services

Az Azure DevOps Services több bérlős használatot használ a költségek csökkentése és a teljesítmény javítása érdekében. Ez a kialakítás sebezhetővé teszi a felhasználókat a teljesítményproblémákkal és még a kimaradásokkal szemben is, ha a megosztott erőforrásaik többi felhasználója kihasználtsága kiugróan magas. Az Azure DevOps tehát korlátozza a felhasználók által használható erőforrásokat, valamint az egyes parancsokra vonatkozó kérések mennyiségét. Ha túllépi ezeket a korlátokat, előfordulhat, hogy a jövőbeli kérések késnek vagy le lesznek tiltva.

További információ: Git-korlátok és ajánlott eljárások a sebességkorlátok elérésének elkerüléséhez.

Globális felhasználás korlátja

Az Azure DevOps jelenleg globális felhasználási korláttal rendelkezik, amely késlelteti az egyes felhasználóktól érkező kéréseket a küszöbértéken túl, ha a megosztott erőforrások túlterheltsége veszélyben van. Ez a korlát kizárólag a kimaradások elkerülésére összpontosít, ha a megosztott erőforrások túlterheltségéhez közel állnak. Az egyes felhasználók általában csak késleltetett kéréseket kapnak az alábbi incidensek valamelyike esetén:

  • Az egyik megosztott erőforrásuk túlterhelt
  • Személyes használatuk meghaladja egy tipikus felhasználó fogyasztásának 200-szorosát egy ötperces (csúsztatott) ablakban

A késés mértéke a felhasználó tartós fogyasztási szintjétől függ. A késések kérésenként néhány ezredmásodperctől 30 másodpercig terjednek. Ha a fogyasztás nullára csökken, vagy az erőforrás már nincs túlterhelve, a késések öt percen belül leállnak. Ha a felhasználás továbbra is magas marad, a késések határozatlan ideig folytatódhatnak az erőforrás védelme érdekében.

Ha egy felhasználói kérés jelentős mértékben késik, az adott felhasználó e-mailt és figyelmeztető szalagcímet kap a weben. A buildszolgáltatás-fiók és az e-mail-címmel nem rendelkező más felhasználók esetében a Project Collection Rendszergazda istrators csoport tagjai kapják meg az e-mailt. For more information, see Usage monitoring.

Ha egy felhasználó kérelmei le lesznek tiltva, a rendszer a 429-ben megadott HTTP-kóddal (túl sok kéréssel) érkező válaszokat a következő üzenethez hasonló üzenettel érkezik:

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

Azure DevOps átviteli egységek (TSTU-k)

Az Azure DevOps-felhasználók számos megosztott erőforrást használnak fel, és a felhasználás a következő tényezőktől függ:

  • Ha nagy számú fájlt tölt fel a verziókövetésbe, nagy mennyiségű terhelést okoz az adatbázisokra és tárfiókokra
  • Az összetett munkaelem-követő lekérdezések adatbázis-terhelést hoznak létre az általuk keresett munkaelemek száma alapján
  • A meghajtóbetöltést úgy hozza létre, hogy letölti a fájlokat a verziókövetésből, és naplókimenetet hoz létre
  • Minden művelet processzort és memóriát használ a szolgáltatás különböző részein

Az Azure DevOps-erőforrás-felhasználás az Azure DevOps átviteli egységeknek vagy TSTU-knak nevezett absztrakt egységekben van kifejezve. A TSTU-k végül a következő elemek keverékét tartalmazzák:

  • Az Azure SQL Database DTU-k az adatbázis-használat mértékeként
  • Az alkalmazásszint és a feladatügynök processzora, a memória és az I/O a számítási felhasználás mértékeként
  • Az Azure Storage sávszélessége a tárterület-használat mértékeként

A TSTU-k jelenleg elsősorban az Azure SQL Database DTU-jaira összpontosítanak, mivel az Azure SQL Database-ek a megosztott erőforrások, amelyeket leggyakrabban túlzott fogyasztás terhel. Egyetlen TSTU az az átlagos terhelés, amelyet az Azure DevOps egyetlen normál felhasználója várhatóan öt percenként generál. A normál felhasználók emellett kiugró terhelést is generálnak. Ezek a csúcsok általában 10 vagy kevesebb TSTU/öt perc. Ritkábban a kiugró értékek akár 100 TSTU-t is elérik.

A globális fogyasztási korlát 200 TSTU egy ötperces csúszásos ablakban.

Javasoljuk, hogy legalább válaszoljon a Retry-After fejlécre. Ha bármelyik válaszban fejlécet Retry-After észlel, várjon, amíg egy másik kérés elküldése előtt eltelik egy kis idő. Ezzel segít az ügyfélalkalmazásnak kevesebb kényszerített késést tapasztalni. Ne feledje, hogy a válasz 200, így nem kell újrapróbálkozási logikát alkalmaznia a kérésre.

Ha lehetséges, javasoljuk a figyelés és X-RateLimit-Limit a fejlécek használatát X-RateLimit-Remaining is. Ezzel hozzávetőlegesen megközelítheti, hogy milyen gyorsan közelíti meg a késési küszöbértéket. Az ügyfél intelligensen reagálhat, és idővel eloszthatja a kéréseit.

Megjegyzés:

Az azure DevOpsba integrálható eszközök és alkalmazások által használt identitásoknak időről időre magasabb sebességre és használati korlátokra lehet szükségük az engedélyezett használati korláton túl. You can get additional rate and usage limits by assigning the Basic + Test Plans access level to the desired identities used by your application. Once the need for higher rate limits are fulfilled, you can go back to the access level that the identity used to have. Az Alapszintű + Tesztcsomagok hozzáférési szint költségét csak az identitáshoz rendelt időpontra számítjuk fel.

A Visual Studio Enterprise-előfizetéshez már hozzárendelt identitások nem rendelhetők hozzá alapszintű és tesztcsomagok hozzáférési szinthez, amíg el nem távolítják őket.

Pipelines

A sebességkorlátozás hasonló az Azure Pipelineshoz. Minden folyamat önálló entitásként lesz kezelve, és nyomon követi a saját erőforrás-felhasználását. Even if build agents are self-hosted, they generate load in the form of cloning and sending logs.

We apply a 200 TSTU limit for an individual pipeline in a sliding 5-minute window. This limit is the same as the global consumption limit for users. Ha a sebességkorlátozás késleltet vagy blokkol egy folyamatot, egy üzenet jelenik meg a csatolt naplókban.

API-ügyfélélmény

Ha a kérelmek késnek vagy le vannak tiltva, az Azure DevOps válaszfejléceket ad vissza, hogy segítsen az API-ügyfeleknek a reagálásban. Bár nem teljesen szabványosított, ezek a fejlécek nagyjából összhangban vannak más népszerű szolgáltatásokkal.

Az alábbi táblázat felsorolja az elérhető fejléceket és azok lényegét. X-RateLimit-DelayKivéve, hogy ezek a fejlécek mind el lesznek küldve, mielőtt a kérések késni kezdenének. Ez a kialakítás lehetővé teszi az ügyfelek számára, hogy proaktívan lassítsák a kérések arányát.

Fejléc neve

Ismertetés

Retry-After

Az RFC 6585 által megadott fejléc, amelyből megtudhatja, hogy mennyi ideig kell várnia, mielőtt a következő kérést az észlelési küszöbérték alá szeretné esni. Egységek: másodperc.

X-RateLimit-Resource

Egy egyéni fejléc, amely az elért szolgáltatást és küszöbérték típusát jelzi. A küszöbértékek típusai és a szolgáltatásnevek idővel és figyelmeztetés nélkül változhatnak. Azt javasoljuk, hogy ezt a sztringet megjelenítse egy ember számára, de ne támaszkodjon rá számításokhoz.

X-RateLimit-Delay

Mennyi ideig késett a kérés. Egységek: másodperc, legfeljebb három tizedesjegy (ezredmásodperc).

X-RateLimit-Limit

A késések elrendelése előtt engedélyezett TSTU-k teljes száma.

X-RateLimit-Remaining

A késleltetés előtt fennmaradó TSTU-k száma. Ha a kérések már késnek vagy le vannak tiltva, az 0.

X-RateLimit-Reset

Ha az összes erőforrás-felhasználás azonnal leáll, a nyomon követett használat 0 TSTU-ra tér vissza. Unix korszakban kifejezve.

Munkakövetési, folyamat- és projektkorlátok

Az Azure DevOps korlátozza a szervezeten belüli projektek számát és az egyes projekteken belül elérhető csapatok számát. Emellett vegye figyelembe a munkaelemek, lekérdezések, hátralékok, táblák, irányítópultok stb. korlátait is. További információ: Munkakövetés, folyamat és projektkorlátok.

Wiki

A projekthez definiált wikik a szokásos adattárkorlátok mellett egyetlen fájlonként legfeljebb 25 MB-ra korlátozódnak.

Szolgáltatáskapcsolatok

A szolgáltatáskapcsolatok létrehozására nem vonatkoznak projektenkénti korlátozások. Lehetnek azonban korlátozások, amelyeket a Microsoft Entra ID-jával szabnak ki. További információkért tekintse át a következő cikkeket: