Omezení rychlosti a 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ů nad prahovou hodnotu, když jsou sdílené prostředky ohroženy zahlcením. Tento limit se zaměřuje výhradně na zabránění výpadkům, když se sdílené prostředky blíží zahlcení. Jednotliví uživatelé obvykle zpožďují požadavky pouze v případě, že dojde k jednomu z následujících incidentů:
- Jeden ze sdílených prostředků je ohrožen zahlcením
- 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 spotřeba přejde na nulu nebo prostředek už není zahlcený, zpoždění se zastaví během pěti minut. Pokud spotřeba zůstává vysoká, zpoždění můžou pokračovat neomezeně dlouho a chránit prostředek.
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 dostanou členové skupiny Kolekce projektů Správa istrators e-mail. 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 (TSTU)
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 nebo jednotky 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é chvíli se jednotky TSTU primárně zaměřují na DTU služby Azure SQL Database, protože azure SQL Database jsou sdílené prostředky nejčastěji zahlcené nadměrnou spotřebou. Jedním TSTU je průměrné zatížení, které očekáváme, že jeden normální uživatel Azure DevOps vygeneruje za pět minut. Normální uživatelé také generují špičky v zatížení. Tyto špičky jsou obvykle 10 nebo méně jednotek TSTU za pět minut. Méně často, špičky jdou až o 100 TSTU.
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 rozprostřet své požadavky v průběhu času.
Poznámka:
Identity používané nástroji a aplikacemi k integraci s Azure DevOps můžou vyžadovat vyšší rychlost a limity využití nad rámec povoleného limitu spotřeby od času. Další limity rychlosti a využití získáte přiřazením úrovně přístupu Basic + Test Plans k požadovaným identitám, které vaše aplikace používá. Jakmile bude splněna potřeba vyšších limitů rychlosti, můžete se vrátit na úroveň přístupu, kterou identita používala. Poplatky se vám účtují za náklady na úroveň přístupu k plánům Basic + Test pouze za dobu, kdy je přiřazená k identitě.
Identity, které už mají přiřazené předplatné sady Visual Studio Enterprise, nelze přiřadit úroveň přístupu k plánům Basic + Test, dokud nebudou odebrány.
Pipelines
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 agenti sestavení v místním prostředí, generují zatížení ve formě klonování a odesílání protokolů.
V klouzavém 5minutovém intervalu použijeme limit 200 TSTU pro jednotlivé kanály. 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.
Prostředí 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.
X-RateLimit-DelayKromě toho se všechny tyto hlavičky odešlou, než se požadavky začnou zpozdit.
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 zadaná v dokumentu RFC 6585 vám sdělí, jak dlouho má čekat, než odešlete další požadavek, který spadá pod 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 uložením zpoždění
X-RateLimit-Remaining
Počet zbývajících jednotek TSTU před zpožděním 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, panely, řídicí panely a další. Další informace najdete v tématu Sledování práce, zpracování 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žby
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: