Ratenbegrenzung
Wir setzen Ratenbegrenzungen durch, um sicherzustellen, dass keine Kunden durch die Nutzung eines anderen Kunden beeinträchtigt werden. Fehlerhafter Integrationscode kann dazu führen, dass in kurzer Zeit zu viele Anfragen gesendet werden, was übermäßig hohe Rechnungen oder längere Wartezeiten in der Warteschlange zur Folge haben kann.
Bei uns gelten drei Assembly-Grenzwerte:
- Kunden können pro Minute bis zu 250 Assemblies erstellen.
- Standardmäßig können in jedem Workspace in jeder Region 2.500 Assemblies gleichzeitig laufen.
- Standardmäßig stehen einer Assembly bis zu 8 Stunden für den Upload und anschließend bis zu weitere 8 Stunden für die Ausführung zur Verfügung. Diese Phasengrenzwerte sind unabhängig voneinander, sodass ihre gesamte Lebensdauer nahezu 16 Stunden betragen kann.
Unserer Erfahrung nach genügt dies selbst höchsten Nutzungsanforderungen, aber Enterprise-Konten können gerne uns kontaktieren, wenn sie höhere Grenzwerte benötigen.
Die Grenzwerte dienen hauptsächlich dazu, Kunden vor Programmierfehlern anderer Kunden zu schützen, die beispielsweise Endlosschleifen verursachen.
Kunden, die einen Grenzwert für die Erstellung oder die Anzahl gleichzeitig laufender Assemblies erreichen, erhalten den Fehler RATE_LIMIT_REACHED und den HTTP-Statuscode
429. Die JSON-Nutzlast dieses Fehlers enthält die Eigenschaft info.retryIn, die die empfohlene
Backoff-Wartezeit in Sekunden vor einem erneuten Versuch der Anfrage angibt. Sie garantiert nicht, dass
nach dieser Wartezeit Kapazität für gleichzeitig laufende Assemblies verfügbar ist. Wenn Sie eines unserer
offiziellen SDKs verwenden, sind geeignete Backoff-Wartezeiten und Wiederholungsversuche auf dieser Grundlage bereits integriert.
Das folgende Beispiel zeigt, wie die JSON-Nutzlast aussehen kann:
{
"error": "RATE_LIMIT_REACHED",
"message": "Request limit reached",
"info": {
"retryIn": 41
}
}
Das Überschreiten des Zeitlimits für den Upload oder die Ausführung einer Assembly wird anders behandelt: Dabei wird
ASSEMBLY_EXPIRED im Assembly Status vermerkt. Die Statusantwort kann HTTP 200 verwenden. Prüfen Sie daher
ihr error-Feld, statt einen HTTP-Erfolg als erfolgreiche Verarbeitung zu werten. Eine Backoff-Wartezeit
setzt eine abgelaufene Assembly nicht fort. Falls sich ihre Eingabedateien noch wiederherstellen lassen,
führen Sie die Assembly erneut aus, um eine neue zu starten.
Ratenbegrenzung bei hoher Anfragefrequenz
Zusätzlich zur oben beschriebenen Ratenbegrenzung gibt es einen weiteren Mechanismus zur Ratenbegrenzung, um Anfragen in zu schneller Folge zu unterbinden. Diese Ratenbegrenzung greift in jedem der folgenden Fälle:
- Wenn zu viele TCP-Verbindungen eines Clients gleichzeitig geöffnet sind
- Wenn ein Client in den letzten 10 Sekunden zu viele TCP-Verbindungen geöffnet hat
- Wenn bei einem Client in den letzten 10 Sekunden zu viele HTTP-Fehlercodes aufgetreten sind
- Wenn ein Client in den letzten 10 Sekunden zu viele HTTP-Anfragen gesendet hat
In diesen Fällen erhält der Client den HTTP-Statuscode 429, und die Antwort enthält die
folgende JSON-Nutzlast:
{
"error": "429 Too Many Requests",
"hostname": "morven.transloadit.com",
"message": "You have sent too many requests in a given amount of time. "
}