Transloadit

Limitation du débit

Nous appliquons des limites de débit afin de garantir qu’aucun client ne soit pénalisé par l’utilisation d’un autre client. Un code d’intégration bogué peut entraîner l’envoi d’un trop grand nombre de requêtes en peu de temps, ce qui peut engendrer des factures excessivement élevées ou des temps d’attente plus longs dans la file.

Nous appliquons trois limites d’Assembly :

  1. Les clients peuvent créer jusqu’à 250 Assemblies par minute.
  2. Par défaut, chaque Workspace peut avoir 2 500 Assemblies en cours d’exécution simultanément dans chaque région.
  3. Par défaut, une Assembly peut consacrer jusqu’à 8 heures au téléversement, puis jusqu’à 8 heures supplémentaires à l’exécution. Ces limites de phase sont indépendantes, de sorte que sa durée de vie totale peut approcher 16 heures.

D’après notre expérience, cela suffit même pour les usages les plus intensifs, mais les comptes entreprise sont libres de nous contacter s’ils ont besoin de limites plus élevées.

Ces limites existent principalement pour protéger les clients des bogues de programmation de type « boucle infinie » d’autres clients.

Les clients qui atteignent une limite de création ou de simultanéité reçoivent une erreur RATE_LIMIT_REACHED et le code de statut HTTP 429. La charge utile JSON de cette erreur contient une propriété info.retryIn qui indique le nombre de secondes du délai d’attente recommandé avant de réessayer la requête. Elle ne garantit pas qu’une capacité simultanée sera disponible après ce délai. Si vous utilisez l’un de nos SDK officiels, des temporisations et des nouvelles tentatives appropriées, fondées sur cette valeur, sont déjà incluses.

Voici un exemple de ce à quoi peut ressembler la charge utile JSON :

{
  "error": "RATE_LIMIT_REACHED",
  "message": "Request limit reached",
  "info": {
    "retryIn": 41
  }
}

Le dépassement de la limite de durée de téléversement ou d’exécution d’une Assembly est différent : il enregistre ASSEMBLY_EXPIRED dans l’Assembly Status. La réponse de statut peut utiliser le code HTTP 200. Examinez donc son champ error au lieu de considérer un succès HTTP comme un succès du traitement. La temporisation ne permet pas de reprendre une Assembly expirée. Si ses fichiers d’entrée peuvent encore être récupérés, rejouez l’Assembly pour en démarrer une nouvelle.

Limite de débit à haute fréquence

En plus de la limitation de débit décrite ci-dessus, il existe un autre mécanisme de limitation de débit destiné à dissuader les requêtes trop rapprochées. Cette limite de débit se déclenche dans chacun des cas suivants :

  • S’il y a trop de connexions TCP ouvertes simultanément depuis un même client
  • Si trop de connexions TCP ont été ouvertes au cours des 10 dernières secondes depuis un même client
  • Si trop de codes d’erreur HTTP se sont produits au cours des 10 dernières secondes pour un même client
  • Si trop de requêtes HTTP ont été envoyées au cours des 10 dernières secondes depuis un même client

Dans ces cas, le client reçoit un code de statut HTTP 429, et la réponse contient la charge utile JSON suivante :

{
  "error": "429 Too Many Requests",
  "hostname": "morven.transloadit.com",
  "message": "You have sent too many requests in a given amount of time. "
}