Sdílet prostřednictvím

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. Tento návrh může způsobit problémy s výkonem nebo výpadky, pokud mají jiní uživatelé sdílených prostředků špičku spotřeby. Aby se tomu zabránilo, Azure DevOps omezuje prostředky, které může každý uživatel využívat, a počet požadavků, které může provést na určité příkazy. Pokud tyto limity překročíte, můžou se budoucí žádosti zpozdit nebo zablokovat.

Přečtěte si další informace o omezeních Gitu a osvědčených postupech, abyste se vyhnuli dosažení limitů rychlosti.

Globální limit spotřeby

Azure DevOps má globální limit spotřeby, který zpožďuje požadavky od jednotlivých uživatelů, když hrozí přetížení sdílených prostředků. Tento limit pomáhá vyhnout se výpadkům, když se sdílené prostředky blíží přetížení. U jednotlivých uživatelů obvykle dochází ke 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 v nebezpečí zahlcení.
  • Jejich osobní spotřeba je více než dvousetnásobné oproti spotřebě typického uživatele v pohyblivém pětiminutovém období.

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. Když spotřeba klesne na nulu nebo prostředek není zahlcený, zpoždění se zastaví během pěti minut. Pokud spotřeba zůstane vysoká, zpoždění mohou pokračovat nekonečně, aby chránily prostředek.

Když se žádost uživatele zpozdí o značné množství, uživatel obdrží e-mail a banner s upozorněním na webu. Pro účet služby sestavení a další účty bez e-mailové adresy obdrží členové skupiny Správci kolekcí projektů e-mail. Další informace najdete v tématu Monitorování využití.

Když se zablokují požadavky jednotlivých uživatelů, uživatel obdrží odpovědi s kódem HTTP 429 (příliš mnoho požadavků) a zprávou podobnou této:

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 úroveň spotřeby závisí na faktorech, jako jsou:

  • Nahrání velkého počtu souborů do správy verzí, což zatěžuje databáze a účty úložiště.
  • Spouštění složitých dotazů na pracovní položky, což zvyšuje zatížení databáze na základě počtu prohledávané pracovní položky.
  • Spouštění sestavení, které stahují soubory ze systému správy verzí a vytvářejí záznamový výstup.
  • Obecné operace, které spotřebovávají procesor a paměť napříč různými částmi služby

K měření této aktivity Azure DevOps vyjadřuje spotřebu prostředků v jednotkách propustnosti Azure DevOps (TSTU). TSTU je abstraktní jednotka zatížení, která představuje kombinaci různých prostředků, včetně:

  • Využití databáze – měřené především prostřednictvím DTU služby Azure SQL Database.
  • Využití výpočetních prostředků – procesor, paměť a vstupně-výstupní operace z aplikačních vrstev a agentů úloh.
  • Využití úložiště – šířka pásma služby Azure Storage

Poznámka:

Jednotky TSTU jsou záměrně abstraktní. Agregují spotřebu prostředků napříč výpočetními, úložnými a databázovými vrstvami v rámci distribuované infrastruktury. Podkladové metriky (procesor, paměť, vstupně-výstupní operace, DTU) nejsou přímo přístupné ani samy o sobě smysluplné. Jednotky TSTU představují jednotný způsob, jak znázorňovat zatížení, což usnadňuje správu a monitorování využití, aniž by se zpřístupňovala úplná složitost jednotlivých komponent prostředků. Pomocí vzorce nemůžete vypočítat využití v jednotkách TSTU pro akci, ale na stránce monitorování využití můžete zjistit, kolik jednotek TSTU spotřebuje operace. Některé operace, jako jsou dotazy na pracovní položky, se liší ve spotřebě, jak vaše organizace roste a mění se, takže možná budete muset pravidelně provádět hodnocení, abyste zůstali přesní.

V současné době se jednotky TSTU zaměřují především na DTU v Azure SQL Database, protože databáze jsou sdíleným zdrojem, který je pravděpodobněji ohrožen přetížením nadměrnou spotřebou.

  • Jedna hodnota TSTU představuje průměrné zatížení vygenerované typickým uživatelem Azure DevOps za pět minut.
  • Normální aktivita uživatelů může generovat špičky 10 jednotek TSTU nebo méně za pět minut.
  • Větší, ale méně časté výkyvy mohou dosáhnout až 100 jednotek TSTU.
  • Globální limit je 200 jednotek TSTU v libovolném klouzavém pětiminutovém intervalu.

Osvědčené postupy

  • Respektovat hlavičku Retry-After: Pokud ji obdržíte v odpovědi, počkejte před odesláním jiného požadavku určený čas. Odpověď stále vrací HTTP 200, takže logika opakování není nutná.
  • Sledování hlaviček X-RateLimit: Pokud je k dispozici, sledujte X-RateLimit-Remaining a X-RateLimit-Limit a odhadněte, jak rychle se blížíte prahové hodnotě. To umožňuje klientovi vyhladit nárůsty požadavků a vyhnout se vynuceným zpožděním.

Poznámka:

Identity používané nástroji a aplikacemi pro integraci s Azure DevOps můžou občas potřebovat vyšší rychlost a limity využití nad rámec povoleného limitu spotřeby. Zvyšte tato omezení přiřazením úrovně přístupu Basic + Test Plans identitám, které vaše aplikace používá. Jakmile už nebudete potřebovat vyšší limity rychlosti, vraťte se na předchozí úroveň přístupu. Účtuje se vám úroveň přístupu k plánům Basic + Test pouze po dobu trvání přiřazenou k identitě. Identity, které už mají přiřazené předplatné sady Visual Studio Enterprise, není možné přiřadit úroveň přístupu k plánům Basic + Test , dokud předplatné neodeberete.

Pipelines

Omezení rychlosti funguje pro Azure Pipelines stejným způsobem. Každý kanál je jednotlivá entita a její spotřeba prostředků se sleduje samostatně. I když jsou agenti sestavení hostovaní sami, generují zatížení klonováním a odesíláním protokolů.

V posuvném časovém okně 5 minut je limit 200 jednotek TSTU pro každý kanál. Tento limit odpovídá globálnímu limitu spotřeby pro uživatele. Pokud omezení rychlosti zpozdí nebo zablokuje potrubí, 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.

V následující tabulce jsou uvedeny dostupné hlavičky a jejich význam. X-RateLimit-DelayKromě toho se všechny tyto hlavičky odesílají před tím, než se požadavky začnou zpozdit. Tento návrh umožňuje klientům proaktivně zpomalit jejich rychlost požadavků.

název záhlaví

popis

Retry-After

Hlavička specifikovaná v RFC 6585 vás informuje, jak dlouho byste měl počkat, než odešlete další požadavek a tím spadnete 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 je žádost zpožděná. 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 zahájením zpoždění Pokud už jsou požadavky zpožděné nebo blokované, je to 0.

X-RateLimit-Reset

Čas, kdy se veškerá spotřeba prostředků okamžitě zastaví, a sledovaná činnost se vrátí 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 každém projektu. Existují také omezení pro pracovní položky, dotazy, backlogy, tabule, řídicí panely a další. Další informace najdete v tématu Sledování práce, procesu a omezení projektu.

Wiki

Kromě obvyklých limitů úložiště může být soubor wikiwebu v projektu až 25 MB.

Připojení služeb

Vytváření připojení služeb není nijak omezené na jednotlivé projekty. Omezení se však můžou vynucovat prostřednictvím Microsoft Entra ID. Další informace najdete v následujících článcích:

Související obsah

  • Last updated on