Freigeben über

Raten-/Nutzungsgrenzen

  • Artikel

Azure DevOps Services

Azure DevOps Services verwendet mandantenübergreifende Mandanten, um Kosten zu senken und die Leistung zu verbessern. Dieses Design lässt Die Benutzer anfällig für Leistungsprobleme und sogar Ausfälle, wenn andere Benutzer ihrer freigegebenen Ressourcen Spitzen beim Verbrauch haben. Daher schränkt Azure DevOps die Ressourcen ein, die Einzelpersonen verbrauchen können, und die Anzahl der Anforderungen, die sie an bestimmte Befehle vornehmen können. Wenn diese Grenzwerte überschritten werden, können zukünftige Anforderungen entweder verzögert oder blockiert werden.

Weitere Informationen finden Sie unter Git-Grenzwerte und bewährte Methoden, um Trefferratenlimits zu vermeiden.

Globale Verbrauchsgrenze

Azure DevOps hat derzeit einen globalen Verbrauchsgrenzwert, der Anforderungen einzelner Benutzer über einen Schwellenwert hinaus verzögert, wenn freigegebene Ressourcen in Gefahr geraten, überfordert zu werden. Dieser Grenzwert konzentriert sich ausschließlich auf das Vermeiden von Ausfällen, wenn gemeinsam genutzte Ressourcen nahezu überfordert werden. Einzelne Benutzer erhalten in der Regel nur verzögerte Anforderungen, wenn einer der folgenden Vorfälle auftritt:

  • Eine ihrer gemeinsamen Ressourcen besteht darin, überwältigt zu werden
  • Ihre persönliche Nutzung überschreitet 200 Mal den Verbrauch eines typischen Benutzers innerhalb eines (gleitenden) fünfminütigen Fensters.

Der Umfang der Verzögerung hängt vom anhaltenden Verbrauchsniveau des Benutzers ab. Verzögerungen reichen von einigen Millisekunden pro Anforderung bis zu 30 Sekunden. Sobald der Verbrauch auf Null geht oder die Ressource nicht mehr überfordert ist, werden die Verzögerungen innerhalb von fünf Minuten beendet. Wenn der Verbrauch hoch ist Standard können Verzögerungen möglicherweise unbegrenzt fortgesetzt werden, um die Ressource zu schützen.

Wenn eine Benutzeranforderung um einen erheblichen Betrag verzögert wird, erhält dieser Benutzer eine E-Mail und ein Warnbanner im Web. Für das Builddienstkonto und andere personen ohne E-Mail-Adresse erhalten Mitglieder der Gruppe "Project-Sammlungsadministratoren" die E-Mail. Weitere Informationen finden Sie unter Auslastungsüberwachung.

Wenn die Anforderungen eines einzelnen Benutzers blockiert werden, werden Antworten mit HTTP-Code 429 (zu viele Anforderungen) empfangen, wobei eine Nachricht ähnlich der folgenden Nachricht ist:

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

Azure DevOps-Durchsatzeinheiten (TSTUs)

Azure DevOps-Benutzer verbrauchen viele freigegebene Ressourcen, und der Verbrauch hängt von den folgenden Faktoren ab:

  • Durch das Hochladen einer großen Anzahl von Dateien in die Versionsverwaltung wird eine große Last für Datenbanken und Speicherkonten erstellt.
  • Komplexe Arbeitsaufgabenverfolgungsabfragen erstellen datenbanklasten basierend auf der Anzahl der Arbeitsaufgaben, die sie durchsuchen
  • Erstellt Laufwerkladevorgang durch Herunterladen von Dateien aus der Versionssteuerung und erzeugt die Protokollausgabe.
  • Alle Vorgänge verbrauchen CPU und Arbeitsspeicher in verschiedenen Teilen des Diensts.

Zur Aufnahme wird der Azure DevOps-Ressourcenverbrauch in abstrakten Einheiten ausgedrückt, die als Azure DevOps-Durchsatzeinheiten oder TSTUs bezeichnet werden. TSTUs enthalten schließlich eine Mischung der folgenden Elemente:

  • Azure SQL-Datenbank DTUs als Maß für den Datenbankverbrauch
  • CPU, Arbeitsspeicher und E/A des Anwendungsebenen- und Auftrags-Agents als Maß für die Berechnungsauslastung
  • Azure Storage-Bandbreite als Maß für den Speicherverbrauch

Derzeit konzentrieren sich TSTUs in erster Linie auf Azure SQL-Datenbank DTUs, da Azure SQL-Datenbank die gemeinsam genutzten Ressourcen am häufigsten durch übermäßigen Verbrauch überfordert sind. Eine einzelne TSTU ist die durchschnittliche Last, die wir erwarten, dass ein einzelner normaler Benutzer von Azure DevOps pro fünf Minuten generiert wird. Normale Benutzer generieren auch Spitzen beim Laden. Diese Spitzen sind in der Regel 10 oder weniger TSTUs pro fünf Minuten. Weniger häufig gehen Spitzen so hoch wie 100 TSTUs.

Der globale Verbrauchsgrenzwert beträgt 200 TSTUs innerhalb eines Schiebefensters von fünf Minuten.

Es wird empfohlen, mindestens auf die Retry-After Kopfzeile zu antworten. Wenn Sie einen Header in einer Retry-After Antwort erkennen, warten Sie, bis einige Zeit vergeht, bevor Sie eine andere Anforderung senden. Dies hilft Ihrer Clientanwendung, weniger erzwungene Verzögerungen zu erzielen. Denken Sie daran, dass die Antwort 200 ist, sodass Sie keine Wiederholungslogik auf die Anforderung anwenden müssen.

Wenn möglich, empfehlen wir ihnen, Die Kopfzeilen zu überwachen und X-RateLimit-Limit zu überwachenX-RateLimit-Remaining. Auf diese Weise können Sie sich nähern, wie schnell Sie sich dem Verzögerungsschwellenwert nähern. Ihr Kunde kann intelligent reagieren und seine Anforderungen im Laufe der Zeit verteilen.

Hinweis

Identitäten, die von Tools und Anwendungen für die Integration in Azure DevOps verwendet werden, benötigen möglicherweise höhere Geschwindigkeits- und Nutzungsgrenzwerte, die von Zeit zu Zeit über das zulässige Verbrauchslimit hinausgehen. Sie können zusätzliche Raten- und Nutzungsbeschränkungen erhalten, indem Sie den gewünschten Identitäten, die von Ihrer Anwendung verwendet werden, die Zugriffsebene Basis + Testpläne zuweisen. Sobald der Bedarf an höheren Ratenlimits erfüllt ist, können Sie zur Zugriffsebene zurückkehren, die die Identität zuvor hatte. Sie werden für die Kosten für die Zugriffsstufe "Basic + TestPläne " nur für den Zeitpunkt berechnet, zu dem sie der Identität zugewiesen ist.

Identitäten, denen bereits ein Visual Studio Enterprise-Abonnement zugewiesen ist, können der Zugriffsebene "Basic + Test Plans" nicht zugewiesen werden, bis sie entfernt werden.

Pipelines

Die Geschwindigkeitsbegrenzung ist für Azure-Pipelines ähnlich. Jede Pipeline wird als einzelne Entität behandelt, wobei der eigene Ressourcenverbrauch nachverfolgt wird. Auch wenn Build-Agents selbstgehostet sind, generieren sie Last durch Klonen und Senden von Protokollen.

Wir wenden einen Grenzwert von 200 TSTU für eine einzelne Pipeline in einem gleitenden 5-Minuten-Fenster an. Dieser Grenzwert ist identisch mit dem globalen Verbrauchsgrenzwert für Benutzer. Wenn eine Pipeline verzögert oder blockiert wird, indem die Rate begrenzt wird, wird eine Meldung in den angefügten Protokollen angezeigt.

API-Clientumgebung

Wenn Anforderungen verzögert oder blockiert werden, gibt Azure DevOps Antwortheader zurück, um API-Clients beim Reagieren zu helfen. Obwohl sie nicht vollständig standardisiert sind, sind diese Header weitgehend mit anderen beliebten Diensten in Einklang.

In der folgenden Tabelle sind die verfügbaren Kopfzeilen und deren Bedeutung aufgeführt. X-RateLimit-DelayMit Ausnahme von , werden alle diese Header gesendet, bevor Anforderungen verzögert werden. Dieses Design bietet Kunden die Möglichkeit, ihre Anzahl von Anforderungen proaktiv zu verlangsamen.

Headername

Beschreibung

Retry-After

Der rfc 6585-angegebene Header, der Ihnen mitgeteilt hat, wie lange gewartet werden muss, bevor Sie Ihre nächste Anforderung senden, um unter den Erkennungsschwellenwert zu fallen. Einheiten: Sekunden.

X-RateLimit-Resource

Ein benutzerdefinierter Header, der den Dienst und den Typ des erreichten Schwellenwerts angibt. Schwellenwerttypen und Dienstnamen können im Laufe der Zeit und ohne Warnung variieren. Es wird empfohlen, diese Zeichenfolge für eine menschliche Zeichenfolge anzuzeigen, aber nicht für die Berechnung zu verwenden.

X-RateLimit-Delay

Wie lange die Anforderung verzögert wurde. Einheiten: Sekunden mit bis zu drei Dezimalstellen (Millisekunden).

X-RateLimit-Limit

Die Gesamtzahl der zulässigen TSTUs, bevor Verzögerungen auferlegt werden.

X-RateLimit-Remaining

Anzahl der TSTUs neu Standard vor der Verzögerung. Wenn Anforderungen bereits verzögert oder blockiert werden, ist sie 0.

X-RateLimit-Reset

Wenn der gesamte Ressourcenverbrauch sofort beendet wurde, würde die nachverfolgte Verwendung zu 0 TSTUs zurückkehren. Ausgedrückt in Unix-Epochenzeit.

Grenzwerte für Arbeitsüberwachung, Prozesse und Projekte

Azure DevOps erzwingt Grenzwerte für die Anzahl der Projekte, die Sie in einer Organisation haben können, und die Anzahl der Teams, die Sie innerhalb jedes Projekts haben können. Beachten Sie außerdem Einschränkungen für Arbeitsaufgaben, Abfragen, Backlogs, Boards, Dashboards und vieles mehr. Weitere Informationen finden Sie unter Arbeitsnachverfolgung, Prozess- und Projektlimits.

Wiki

Zusätzlich zu den üblichen Repositorygrenzwerten sind wikis, die für ein Projekt definiert sind, auf 25 MB pro einzelne Datei beschränkt.

Dienstverbindungen

Für das Erstellen von Dienstverbindungen gelten keine projektspezifischen Grenzwerte. Es kann jedoch Beschränkungen geben, die über die Microsoft Entra-ID auferlegt werden. Weitere Informationen finden Sie in den folgenden Artikeln: