API Dynamic Media Open et passerelle de ressources : comprendre et résoudre les limites de débit d’API
Une activité d’API à volume élevé peut renvoyer des erreurs HTTP 429 lorsque les modèles de requête dépassent les limites de débit dynamique. Le problème est généralement provoqué par le trafic en rafale, les interrogations répétées ou les workflows à plusieurs étapes où chaque appel est comptabilisé séparément, tandis que la mise en cache peut retarder le moment où les mises à jour sont visibles. La résolution se concentre sur la confirmation du ralentissement dans les journaux, la réduction des requêtes inutiles, le respect du comportement du cache et l’application d’une rétrogradation exponentielle. Les réponses stables reviennent après l’ajustement des modèles de requête et du comportement des reprises.
Description description
Environnement :
- Workflows d’ingestion de ressources basés sur l’API
- Workflows de récupération des métadonnées
- Intégrations de la diffusion des ressources ou de la passerelle
- Clients effectuant des requêtes d’API répétées ou à volume élevé
Problème/Symptômes
- Les points d’entrée de l’API renvoient des réponses HTTP 429 Too many requests intermittentes, qui peuvent être confirmées dans les journaux d’application ou les données de surveillance et liées aux points d’entrée affectés.
- Le problème est plus visible lors du trafic en rafale ou d’autres périodes de demande de volume élevé, ce qui indique un ralentissement en cas de charge de requête plus lourde.
- Les workflows à plusieurs étapes peuvent être affectés de manière disproportionnée, car une seule opération peut générer plusieurs requêtes d’API comptabilisées, telles que la recherche, la recherche de métadonnées, le lancement du chargement et l’envoi du chargement.
- L’activité répétée du client, y compris l’interrogation, les reprises ou l’échec de réutilisation des réponses mises en cache, peut augmenter le volume des requêtes et contribuer à la limitation.
- Les mises à jour des ressources ou du contenu peuvent sembler retardées, car les réponses mises en cache peuvent persister pendant 10 minutes maximum. Ce comportement peut être validé par le biais d’en-têtes de réponse tels que
Cache-Control: max-age=600. - Dans ce cas, le contenu mis à jour n’est visible qu’après 1 à 10 minutes, ce qui indique un délai de la couche de cache plutôt qu’un échec d’API distinct.
Cause principale :
L’API utilise une limitation de débit dynamique basée sur la charge plutôt qu’un seuil fixe de requêtes par seconde. Les pics de trafic, les interrogations non optimisées et les flux de chargement ou de requête à plusieurs étapes peuvent pousser le volume des requêtes au-delà des limites normales et déclencher une limitation. En outre, les réponses peuvent être mises en cache avec Cache-Control: max-age=600, de sorte que les caches en aval puissent continuer à servir les données plus anciennes après la mise à jour de l’origine.
Résolution resolution
Suivez les étapes ci-dessous pour réduire le ralentissement et confirmer la récupération.
- Consultez les journaux d’application ou la surveillance des API pour identifier les réponses HTTP 429 Too Many Requests. Le résultat attendu est une preuve évidente de limitation liée aux points d’entrée d’API affectés. Vérifiez que les réponses sont répétables dans le même workflow et ne sont pas isolées dans des requêtes non liées.
- Recherchez des modèles de requête à plusieurs étapes dans les workflows de chargement ou de requête. Le résultat attendu est l’identification des flux où chaque appel contribue séparément au volume global des demandes. Vérifiez que les séquences de requêtes telles que la recherche, la recherche de métadonnées, le lancement du chargement et l’envoi du chargement sont toutes comptabilisées.
- Examinez le comportement des reprises et la mise en cache des réponses, y compris les
Cache-Control: max-age=600. Le résultat attendu est la recherche d’appels répétés qui peuvent être supprimés, retardés ou mis en cache. Vérifiez que le client respecte la durée de mise en cache et ne demande pas immédiatement à nouveau les mêmes données. - Réduisez le volume des requêtes en mettant en cache les réponses si possible et en évitant les récupérations de métadonnées ou les appels en double répétés. Le résultat attendu est un débit d’API inférieur et moins de requêtes limitées. Vérifiez la modification en examinant les journaux ou en surveillant pour confirmer que le volume des requêtes diminue et que les réponses 429 se produisent moins souvent.
- Validez le comportement du cache lors de la recherche de mises à jour. Le résultat attendu est la reconnaissance du fait que le contenu actualisé peut apparaître après une propagation normale du cache plutôt que immédiatement. Pour ce faire, effacez le cache du navigateur, relancez la requête et confirmez que le contenu actualisé s’affiche dans la fenêtre de cache prévue de 1 à 10 minutes.
- Appliquez une temporisation exponentielle afin que le client attende progressivement plus longtemps avant de réessayer après une réponse 429. Le résultat attendu est une fréquence plus faible des événements de limitation. Vérifiez l’amélioration en surveillant les journaux après le déploiement des modifications de reprise et en confirmant que les réponses 429 répétées déclinent.
- Si le trafic se rapproche constamment des limites de service, vérifiez si le traitement par lots des demandes ou les modifications de conception des workflows peuvent réduire les appels par article. Le résultat attendu est un comportement de réponse plus stable dans un trafic normal. Vérifiez que les modèles de requête restent stables pendant une utilisation standard et ne déclenchent plus de limitation répétée.
- Si le ralentissement se poursuit après l’optimisation de la requête, collectez les horodatages, les points d’entrée affectés, les en-têtes de requête et de réponse, le taux de requête estimé et les détails de stratégie de cache avant de contacter l’assistance. Le résultat attendu est un enregistrement technique complet qui permet une enquête plus rapide. Vérifiez que les informations collectées reflètent les demandes limitées et les conditions dans lesquelles elles se produisent.
Si HTTP 429 Too Many Requests les réponses continuent après que le volume des requêtes a été réduit, que la mise en cache fonctionne comme prévu, que le comportement de reprise a été mis à jour et que la limitation est toujours répétable pour les mêmes workflows d’API, envoyez un ticket à l’assistance Adobe et incluez les horodatages, les points d’entrée affectés, les en-têtes de requête et de réponse, le taux de requête estimé et les détails de stratégie de mise en cache collectés pendant la résolution des problèmes.