Ratenbegrenzungen

Azure DevOps Services

Azure DevOps, z. B. viele Software-as-a-Service-Lösungen, verwendet Mehr-Mandanten, um Kosten zu reduzieren und die Leistung zu verbessern. Dieses Design lässt Benutzer anfällig für Leistungsprobleme und sogar Ausfälle, wenn andere Benutzer ihrer freigegebenen Ressourcen Übergänge in ihrem Verbrauch haben. Um diese Probleme zu bekämpfen, schränkt Azure DevOps die Ressourcen ein, die einzelpersonen nutzen 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.

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 personen ohne E-Mail-Adresse erhalten Mitglieder der Gruppe "Project Collection Administrators" die E-Mail. Weitere Informationen finden Sie unter Verwendungsüberwachung.

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

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

Weitere Informationen finden Sie in den folgenden Artikeln:

Aktuelle Ratelimits

Azure DevOps verfügt derzeit über einen globalen Verbrauchsgrenzwert. Dieser Grenzwert verzögert Anforderungen von einzelnen Benutzern über einen Schwellenwert hinaus, wenn freigegebene Ressourcen gefahr sind, überfordert zu werden.

Globale Verbrauchsgrenzwerte

Dieser Grenzwert konzentriert sich ausschließlich auf die Vermeidung von Ausfallen, wenn freigegebene Ressourcen nahe sind, überfordert zu werden. Einzelne Benutzer haben in der Regel nur ihre Anforderungen verzögert, wenn eine der folgenden Auftritte auftritt:

  • Eine ihrer freigegebenen Ressourcen ist gefährdet, überfordert zu werden
  • Ihre persönliche Nutzung überschreitet 200 Mal den Verbrauch eines typischen Benutzers innerhalb eines (gleitenden) fünfminütigen Fensters

Der Betrag der Verzögerung hängt von dem dauerhaften Verbrauch 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, beenden die Verzögerungen innerhalb von fünf Minuten. Wenn der Verbrauch weiterhin hoch bleibt, können Verzögerungen auf unbestimmte Zeit fortgesetzt werden, um die Ressource zu schützen.

Azure DevOps-Durchsatzeinheiten (TSTUs)

Azure DevOps-Benutzer nutzen viele freigegebene Ressourcen, und der Verbrauch hängt von vielen Faktoren ab. Beispiel:

  • Durch das Hochladen einer großen Anzahl von Dateien in die Versionsverwaltung wird eine große Anzahl von Lasten für Datenbanken und Speicherkonten erstellt.
  • Komplexe Arbeitsaufgabenverfolgungsabfragen erstellen Datenbankladevorgänge basierend auf der Anzahl der arbeitsbezogenen Elemente, die sie durchsuchen.
  • Erstellt die Laufwerklast, indem Dateien aus der Versionssteuerung heruntergeladen werden, die Protokollausgabe erstellt wird usw.
  • Alle Vorgänge verbrauchen CPU und Arbeitsspeicher in verschiedenen Teilen des Diensts.

Um all dies zu berücksichtigen, wird der Ressourcenverbrauch von Azure DevOps in abstrakten Einheiten namens Azure DevOps-Durchsatzeinheiten oder TSTUs ausgedrückt.

TSTUs enthalten schließlich eine Mischung aus folgenden Komponenten:

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

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

Eine einzelne TSTU ist die durchschnittliche Auslastung, 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.

Pipelines

Die Ratelimitierung ist für Azure-Pipelines ähnlich. Jede Pipeline wird als einzelne Entität behandelt, wobei der Ressourcenverbrauch nachverfolgt wird. Auch wenn Build-Agents selbst gehostet werden, generieren sie Ladevorgänge in Form von Klonen und Senden von Protokollen.

Wir wenden einen TSTU-Grenzwert von 200 FÜR eine einzelne Pipeline in einem gleitenden 5-Minütigen Fenster an. Dieser Grenzwert entspricht dem globalen Verbrauchslimit für Benutzer. Wenn eine Pipeline verzögert oder durch Einschränkung der Rate blockiert wird, wird eine Meldung in den angefügten Protokollen angezeigt.

API-Clienterfahrung

Wenn Anforderungen verzögert oder blockiert werden, gibt Azure DevOps Antwortheader zurück, um API-Clients zu reagieren. Obwohl diese Header nicht vollständig standardisiert sind, sind diese Kopfzeilen allgemein in Übereinstimmung mit anderen beliebten Diensten.

In der folgenden Tabelle sind die verfügbaren Kopfzeilen und die Bedeutung aufgeführt. Mit Ausnahme von X-RateLimit-Delay, werden alle diese Header gesendet, bevor Anforderungen beginnen, verzögert zu 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 wird, wie lange Sie warten müssen, 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 einem Menschen anzuzeigen, aber nicht darauf zu vertrauen, um die Berechnung zu erleichtern.


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 verhängt werden.


X-RateLimit-Remaining

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


X-RateLimit-Reset

Wenn alle Ressourcenverbrauch sofort beendet wurden, wird die nachverfolgte Nutzung auf 0 TSTUs zurückgegeben. Ausgedrückt in der Unix-Epochenzeit.


Empfehlungen

Es wird empfohlen, zumindest auf den Retry-After Header zu antworten. Wenn Sie einen Retry-After Header in einer Antwort erkennen, warten Sie, bis diese Zeit vor dem Senden einer anderen Anforderung übergeben wurde. Dies hilft Ihrer Clientanwendung, weniger erzwungene Verzögerungen zu erzielen. Beachten Sie, dass die Antwort 200 ist, sodass Sie keine Wiederholungslogik auf die Anforderung anwenden müssen.

Wenn möglich, empfehlen wir ihnen, die Kopf- und Kopfzeilen zu überwachen und X-RateLimit-Limit zu überwachenX-RateLimit-Remaining.

Dies ermöglicht Ihnen die Ungefähre, wie schnell Sie dem Verzögerungsschwellenwert nähern.

Ihr Kunde kann intelligent reagieren, indem seine Anforderungen im Laufe der Zeit verteilt werden.