Míra a omezení využití
Služby Azure DevOps
Azure DevOps Services využívá víceklientské architektury ke snížení nákladů a zlepšení výkonu. Díky tomuto návrhu jsou uživatelé zranitelní vůči problémům s výkonem a dokonce výpadkům, když jiní uživatelé sdílených prostředků mají špičky ve své spotřebě. Azure DevOps tedy omezuje prostředky, které můžou jednotlivci využívat, a množství požadavků, které můžou provést na určité příkazy. Při překročení těchto limitů můžou být budoucí žádosti zpožděné nebo zablokované.
Další informace najdete v tématu Omezení Gitu a osvědčené postupy, abyste se vyhnuli dosažení limitů rychlosti.
Globální limit spotřeby
Azure DevOps má v současné době globální limit spotřeby, který zpožďuje požadavky jednotlivých uživatelů, když překročí prahovou hodnotu, když je hrozí přetížení sdílených prostředků. Tento limit se zaměřuje výhradně na zabránění výpadkům, když se sdílené prostředky blíží zahlcení. U jednotlivých uživatelů dochází k obvykle zpoždění požadavků pouze v případě, že dojde k jednomu z následujících incidentů:
- Jeden ze sdílených prostředků je ohrožen, že bude přetížen.
- Jejich osobní využití překračuje 200krát spotřebu typického uživatele během pětiminutového (posuvného) intervalu.
Množství zpoždění závisí na trvalé úrovni spotřeby uživatele. Zpoždění se pohybuje od několika milisekund na požadavek až do 30 sekund. Jakmile se spotřeba sníží na nulu nebo zdroj už není zahlcený, zpoždění se zastaví během pěti minut. Pokud spotřeba zůstane vysoká, zpoždění můžou pokračovat neomezeně dlouho, neboť chrání zdroj.
Když se žádost uživatele zpozdí o značné množství, obdrží tento uživatel e-mail a upozornění na webu. Pro účet služby sestavení a další uživatele bez e-mailové adresy obdrží e-mail členové skupiny administrátorů kolekcí projektů. Další informace najdete v tématu Monitorování využití.
Když se zablokují požadavky jednotlivých uživatelů, obdrží se odpovědi s kódem HTTP 429 (příliš mnoho požadavků) se zprávou podobnou následující zprávě:
TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.
Jednotky propustnosti Azure DevOps
Uživatelé Azure DevOps spotřebovávají mnoho sdílených prostředků a spotřeba závisí na následujících faktorech:
- Nahrání velkého počtu souborů do správy verzí vytváří velké zatížení databází a účtů úložiště.
- Složité dotazy pro sledování pracovních položek vytvářejí zatížení databáze na základě počtu pracovních položek, které prohledávají.
- Sestavení načtení jednotky stažením souborů ze správy verzí a vytvořením výstupu protokolu
- Všechny operace spotřebovávají procesor a paměť v různých částech služby.
Pro přizpůsobení se spotřeba prostředků Azure DevOps vyjadřuje v abstraktních jednotkách označovaných jako jednotky propustnosti Azure DevOps (TSTU). Jednotky TSTU nakonec obsahují kombinaci následujících položek:
- DTU služby Azure SQL Database jako měřítko spotřeby databáze
- Procesor, paměť a vstupně-výstupní operace aplikační vrstvy a agenta úloh jako míra spotřeby výpočetních prostředků
- Šířka pásma služby Azure Storage jako míra spotřeby úložiště
V současné době se jednotky TSTU primárně zaměřují na DTU služby Azure SQL Database, protože Azure SQL Databáze jsou sdílené prostředky, které bývají nejčastěji přetížené nadměrnou spotřebou. Jedna hodnota TSTU představuje průměrné zatížení, které očekáváme, že typický uživatel Azure DevOps vytvoří během pěti minut. Typickí uživatelé také generují špičky v zatížení. Tyto špičky jsou obvykle 10 nebo méně jednotek TSTU za pět minut. Špičky jdou až na 100 TSTUů, méně často.
Globální limit spotřeby je 200 jednotek TSTU během posuvného pětiminutového intervalu.
Doporučujeme, abyste alespoň odpověděli na hlavičku Retry-After . Pokud v jakékoli odpovědi zjistíte hlavičku Retry-After , počkejte, než odešlete jiný požadavek. Díky tomu může vaše klientská aplikace zaznamenat méně vynucených zpoždění. Mějte na paměti, že odpověď je 200, takže u požadavku nemusíte použít logiku opakování.
Pokud je to možné, doporučujeme dále monitorovat X-RateLimit-Remaining a X-RateLimit-Limit hlavičky. To vám umožní odhadnout, jak rychle se blížíte prahové hodnotě zpoždění. Váš klient může inteligentně reagovat a rozložit své požadavky v průběhu času.
Poznámka:
Identity používané nástroji a aplikacemi k integraci s Azure DevOps můžou občas potřebovat vyšší rychlost a limity využití nad rámec povoleného limitu spotřeby. Tato omezení můžete zvýšit přiřazením úrovně přístupu k základním a testovacím plánům požadovaným identitám, které vaše aplikace používá. Jakmile je potřeba splnit vyšší limity sazeb, můžete se vrátit na předchozí úroveň přístupu. Účtují se vám poplatky za úroveň přístupu k základním a testovacím plánům pouze po dobu trvání přiřazenou k identitě.
Identitám, kterým již bylo přiřazeno předplatné Visual Studio Enterprise, nelze přiřadit přístupovou úroveň Basic + Test Plans, dokud nebudou odstraněny.
Potrubní systémy
Omezení rychlosti je podobné pro Azure Pipelines. Každý kanál se považuje za jednotlivou entitu se sledovaným vlastním využitím prostředků. I když jsou build agenti na vlastním serveru, generují zatížení ve formě klonování a odesílání protokolů.
Používáme limit 200 TSTU pro jednotlivý pipeline v posuvném 5minutovém okně. Tento limit je stejný jako globální limit spotřeby pro uživatele. Pokud se kanál zpozdí nebo zablokuje omezením rychlosti, zobrazí se v připojených protokolech zpráva.
Zkušenost klienta rozhraní API
Když se požadavky zpozdí nebo zablokují, Azure DevOps vrátí hlavičky odpovědí, které pomáhají klientům rozhraní API reagovat. I když nejsou plně standardizované, tyto hlavičky jsou obecně v souladu s dalšími oblíbenými službami.
Následující tabulka uvádí dostupné záhlaví a jejich význam.
Kromě X-RateLimit-Delay se všechny tyto hlavičky odešlou, než se požadavky začnou zdržovat.
Díky tomuto návrhu mají klienti příležitost aktivně zpomalovat míru požadavků.
název záhlaví
popis
Retry-After
Hlavička specifikovaná v RFC 6585 vám sdělí, jak dlouho máte čekat, než odešlete další požadavek, abyste nepřekročili prahovou hodnotu detekce. Jednotky: sekundy.
X-RateLimit-Resource
Vlastní hlavička označující službu a typ prahové hodnoty, která byla dosažena. Typy prahových hodnot a názvy služeb se můžou v průběhu času lišit a bez upozornění. Tento řetězec doporučujeme zobrazit člověku, ale nespoléháme na něj při výpočtu.
X-RateLimit-Delay
Jak dlouho byla žádost zpožděna. Jednotky: sekundy s až třemi desetinnými místy (milisekundy).
X-RateLimit-Limit
Celkový počet povolených jednotek TSTU před zavedením zpoždění
X-RateLimit-Remaining
Počet zbývajících jednotek TSTU před tím, než dojde ke zpoždění. Pokud už jsou požadavky zpožděné nebo blokované, je to 0.
X-RateLimit-Reset
Čas, kdy pokud se všechna spotřeba prostředků okamžitě zastavila, by se sledované využití vrátilo na 0 jednotek TSTU. Vyjádřeno v unixovém epochovém čase.
Sledování práce, proces a limity projektů
Azure DevOps omezuje počet projektů, které můžete mít v organizaci, a počet týmů, které můžete mít v rámci každého projektu. Mějte také na paměti omezení pro pracovní položky, dotazy, backlogy, nástěnky a další. Další informace najdete v tématu Sledování práce, procesu a omezení projektu.
Wiki
Kromě obvyklých limitů úložiště jsou wikiweby definované pro projekt omezené na 25 MB na jeden soubor.
Připojení služeb
Vytváření připojení služeb není nijak omezené na jednotlivé projekty. Můžou však existovat omezení, která se vynucují prostřednictvím ID Microsoft Entra. Další informace najdete v následujících článcích: