Ratenbegrenzungen

Azure DevOps Services

Azure DevOps verwendet wie viele Software-as-a-Service-Lösungen Mehrmandantenfähigkeit, um Kosten zu senken und die Leistung zu verbessern. Dieser Entwurf macht Benutzer anfällig für Leistungsprobleme und sogar Ausfälle, wenn andere Benutzer ihrer gemeinsam genutzten Ressourcen Spitzen beim Verbrauch aufweisen. Um diese Probleme zu beheben, schränken Azure DevOps die Ressourcen ein, die Einzelpersonen nutzen können, und die Menge der Anforderungen, die sie an bestimmte Befehle stellen können. Wenn diese Grenzwerte überschritten werden, können zukünftige Anforderungen verzögert oder blockiert werden.

Wenn die Anforderungen eines Benutzers um einen erheblichen Betrag verzögert werden, erhält dieser Benutzer eine E-Mail und sieht ein Warnbanner im Web. Für das Builddienstkonto und andere Konten ohne E-Mail-Adresse erhalten Mitglieder der Gruppe Project Sammlungsadministratoren die E-Mail. Weitere Informationen finden Sie unter Nutzungsüberwachung.

Wenn die Anforderungen eines einzelnen Benutzers blockiert werden, werden Antworten mit dem HTTP-Code 429 (zu viele Anforderungen) mit einer Meldung ähnlich der folgenden empfangen:

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

Aktuelle Ratenlimits

Azure DevOps verfügt derzeit über ein globales Verbrauchslimit. Dieser Grenzwert verzögert Anforderungen einzelner Benutzer über einen Schwellenwert hinaus, wenn die Gefahr besteht, dass freigegebene Ressourcen überlastet werden.

Globales Verbrauchslimit

Dieser Grenzwert konzentriert sich ausschließlich darauf, Ausfälle zu vermeiden, wenn freigegebene Ressourcen nahezu überlastet sind. Einzelne Benutzer haben ihre Anforderungen in der Regel nur verzögert, wenn einer der folgenden Auftritte auftritt:

  • Für eine der gemeinsam genutzten Ressourcen besteht die Gefahr, dass sie überlastet ist.
  • Ihre persönliche Nutzung überschreitet das 200-fache der Nutzung eines typischen Benutzers innerhalb eines (gleitenden) fünfminütigen Fensters.

Die Verzögerung hängt vom dauerhaften Verbrauch des Benutzers ab. Verzögerungen reichen von einigen Millisekunden pro Anforderung bis zu 30 Sekunden. Sobald der Verbrauch 0 (null) erreicht oder die Ressource nicht mehr überlastet ist, werden die Verzögerungen innerhalb von fünf Minuten beendet. Wenn der Verbrauch weiterhin hoch ist, können Verzögerungen unbegrenzt fortgesetzt werden, um die Ressource zu schützen.

Azure DevOps-Durchsatzeinheiten (TSTUs)

Azure DevOps Benutzer viele freigegebene Ressourcen nutzen, hängt die Nutzung von vielen Faktoren ab. Beispiel:

  • Das Hochladen einer großen Anzahl von Dateien in die Versionskontrolle führt zu einer großen Last für Datenbanken und Speicherkonten.
  • Komplexe Abfragen zur Arbeitselementnachverfolgung erstellen eine Datenbankauslastung basierend auf der Anzahl der Arbeitselemente, die sie durchsuchen.
  • Erstellt die Laufwerklast durch Herunterladen von Dateien aus der Versionskontrolle, Erzeugen von Protokollausgaben usw.
  • Alle Vorgänge verbrauchen CPU und Arbeitsspeicher in verschiedenen Teilen des Diensts.

Um all dies zu berücksichtigen, wird Azure DevOps Ressourcenverbrauch in abstrakten Einheiten ausgedrückt, die als Azure DevOps Durchsatzeinheiten oder TSTUs bezeichnet werden.

TSTUs enthalten schließlich eine Mischung aus folgendem Code:

  • Azure SQL-Datenbank DTUs als Maß für den Datenbankverbrauch
  • CPU, Arbeitsspeicher und E/A auf Anwendungsebene und Auftrags-Agent als Maß für den Computeverbrauch
  • Azure Storage Bandbreite als Maß für den Speicherverbrauch

Vorerst konzentrieren sich TSTUs hauptsächlich auf Azure SQL-Datenbank DTUs, da Azure SQL Datenbanken die gemeinsam genutzten Ressourcen sind, die am häufigsten durch übermäßigen Verbrauch überlastet sind.

Eine einzelne TSTU ist die durchschnittliche Last, die ein einzelner normaler Benutzer von Azure DevOps pro fünf Minuten generieren wird. Normale Benutzer generieren auch Lastspitzen. Diese Spitzen liegen in der Regel bei 10 oder weniger TSTUs pro fünf Minuten. Weniger häufig werden Spitzen von bis zu 100 TSTUs verwendet. Das globale Nutzungslimit beträgt 200 TSTUs innerhalb eines gleitenden Fünf-Minuten-Zeitfensters.

Pipelines

Die Ratenbegrenzung ist für Azure Pipelines ähnlich. Jede Pipeline wird als einzelne Entität behandelt, deren eigener Ressourcenverbrauch nachverfolgt wird. Selbst wenn Build-Agents selbst gehostet werden, generieren sie Auslastungen in Form von 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 entspricht dem globalen Nutzungslimit für Benutzer. Wenn eine Pipeline durch Ratenbegrenzung verzögert oder blockiert wird, wird in den angefügten Protokollen eine Meldung angezeigt.

API-Clienterfahrung

Wenn Anforderungen verzögert oder blockiert werden, gibt Azure DevOps Antwortheader zurück, damit API-Clients reagieren können. Obwohl diese Header nicht vollständig standardisiert sind, entsprechen sie weitgehend anderen beliebten Diensten.

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

Headername

Beschreibung


Retry-After

Der rfc 6585-angegebene Header, der gesendet wird, um Ihnen mitzuteilen, wie lange gewartet werden soll, 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 Schwellenwerts angibt, der erreicht wurde. Schwellenwerttypen und Dienstnamen können im Laufe der Zeit und ohne Warnung variieren. Es wird empfohlen, diese Zeichenfolge einem Menschen anzuzeigen, sich aber nicht für die Berechnung darauf zu verlassen.


X-RateLimit-Delay

Gibt an, wie lange die Anforderung verzögert wurde. Einheiten: Sekunden mit bis zu drei Dezimalstellen (Millisekunden).


X-RateLimit-Limit

Gesamtzahl der zulässigen TSTUs, bevor Verzögerungen auftreten.


X-RateLimit-Remaining

Anzahl der verbleibenden TSTUs, bevor sie verzögert werden. Wenn Anforderungen bereits verzögert oder blockiert werden, ist dies 0.


X-RateLimit-Reset

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


Empfehlungen

Es wird empfohlen, mindestens auf den Retry-After Header zu reagieren. Wenn Sie einen Header in einer Retry-After Antwort erkennen, warten Sie, bis diese Zeitspanne verstrichen ist, bevor Sie eine weitere Anforderung senden. Dies hilft Ihrer Clientanwendung, weniger erzwungene Verzögerungen zu erleben. Beachten Sie, dass die Antwort 200 lautet, sodass Sie keine Wiederholungslogik auf die Anforderung anwenden müssen.

Wenn möglich, wird außerdem empfohlen, die Header und X-RateLimit-Limit zu überwachenX-RateLimit-Remaining.

Auf diese Weise können Sie ungefähr wissen, wie schnell Sie sich dem Verzögerungsschwellenwert nähern.

Ihr Client kann intelligent reagieren, indem er seine Anforderungen im Laufe der Zeit verteilt.