Dynamic Media OpenAPI e Asset Gateway: comprendere e risolvere i limiti di velocità delle API
L’attività API con volumi elevati può restituire errori HTTP 429 quando i modelli di richiesta superano i limiti di velocità dinamica. Il problema è comunemente causato da traffico burst, polling ripetuto o flussi di lavoro in più passaggi in cui ogni chiamata viene conteggiata separatamente, mentre la memorizzazione nella cache può ritardare quando gli aggiornamenti diventano visibili. La risoluzione si concentra sulla conferma della limitazione nei registri, sulla riduzione delle richieste non necessarie, sul rispetto del comportamento della cache e sull’applicazione di un backoff esponenziale. Dopo la regolazione dei pattern di richiesta e del comportamento dei nuovi tentativi, vengono restituite risposte stabili.
Descrizione description
Ambiente:
- Flussi di lavoro per l’inserimento di risorse basate su API
- Flussi di lavoro per il recupero dei metadati
- Consegna delle risorse o integrazioni gateway
- Client che eseguono richieste API ripetute o con volumi elevati
Problema/Sintomi
- Gli endpoint API restituiscono risposte HTTP 429 Troppe richieste intermittenti, che possono essere confermate nei registri dell’applicazione o nei dati di monitoraggio e collegate agli endpoint interessati.
- Il problema è più evidente durante il traffico burst o altri periodi di richiesta di volume elevato, indicando una limitazione in caso di carico di richiesta più elevato.
- I flussi di lavoro in più passaggi possono essere interessati in modo sproporzionato perché una singola operazione può generare diverse richieste API conteggiate, come la ricerca, la ricerca di metadati, l’avvio del caricamento e l’invio del caricamento.
- Le attività client ripetute, tra cui polling, nuovi tentativi o il mancato riutilizzo delle risposte memorizzate nella cache, possono aumentare il volume delle richieste e contribuire alla limitazione.
- Gli aggiornamenti di risorse o contenuti possono apparire ritardati perché le risposte memorizzate nella cache possono persistere per un massimo di 10 minuti; questo comportamento può essere convalidato tramite intestazioni di risposta come
Cache-Control: max-age=600. - In questi casi, il contenuto aggiornato può diventare visibile solo dopo 1-10 minuti, il che punta a un ritardo a livello di cache anziché a un errore API separato.
Causa principale:
L’API utilizza un limite di velocità dinamico basato sul carico, anziché una soglia fissa di richieste al secondo. Picchi di traffico, polling non ottimizzato e flussi di caricamento o query in più passaggi possono spingere il volume delle richieste oltre i limiti di integrità e attivare la limitazione. Inoltre, le risposte possono essere memorizzate nella cache con Cache-Control: max-age=600, pertanto le cache a valle possono continuare a fornire dati meno recenti dopo l’aggiornamento dell’origine.
Risoluzione resolution
Utilizzare i passaggi seguenti per ridurre la limitazione e confermare il ripristino.
- Esaminare i registri applicazioni o il monitoraggio API per identificare HTTP 429 Troppe richieste risposte. Il risultato atteso è una chiara evidenza di limitazione associata agli endpoint API interessati. Verifica che le risposte siano ripetibili nello stesso flusso di lavoro e non siano isolate in richieste non correlate.
- Esamina i flussi di lavoro di caricamento o query per individuare i pattern di richiesta a più passaggi. Il risultato atteso è l’identificazione dei flussi in cui ogni chiamata contribuisce separatamente al volume complessivo delle richieste. Verifica che vengano conteggiate tutte le sequenze di richieste come ricerca, ricerca di metadati, avvio del caricamento e invio del caricamento.
- Rivedi il comportamento dei tentativi e il caching delle risposte, incluso
Cache-Control: max-age=600. Il risultato atteso è la ricerca di chiamate ripetute che possono essere rimosse, ritardate o memorizzate nella cache. Verifica che il client rispetti la durata della cache e non richieda immediatamente gli stessi dati. - Riduci il volume delle richieste memorizzando nella cache le risposte laddove possibile ed evitando ripetuti recuperi di metadati o chiamate duplicate. Il risultato atteso è un throughput API inferiore e un numero inferiore di richieste limitate. Verifica la modifica esaminando i registri o il monitoraggio per confermare che il volume delle richieste diminuisca e che le risposte 429 si verifichino con minore frequenza.
- Convalida il comportamento della cache durante il controllo degli aggiornamenti. Il risultato atteso riconosce che il contenuto aggiornato può apparire dopo la normale propagazione della cache anziché immediatamente. Verifica l’operazione cancellando la cache del browser, ritentando la richiesta e confermando che il contenuto aggiornato venga visualizzato nella finestra della cache prevista da 1 a 10 minuti.
- Applica il backoff esponenziale in modo che il client attenda progressivamente più tempo prima di riprovare dopo una risposta 429. Il risultato atteso è una frequenza inferiore di eventi di limitazione. Verifica il miglioramento monitorando i registri dopo la distribuzione delle modifiche dei nuovi tentativi e confermando che le risposte 429 ripetute si rifiutano.
- Se il traffico si avvicina in modo coerente ai limiti del servizio, controlla se la gestione in batch delle richieste o le modifiche alla progettazione del flusso di lavoro possono ridurre le chiamate per articolo. Il risultato atteso è un comportamento di risposta più stabile in condizioni di traffico normale. Verifica che i pattern di richiesta rimangano costanti durante l’utilizzo tipico e non attivino più la limitazione ripetuta.
- Se la limitazione continua dopo l’ottimizzazione delle richieste, raccogli marche temporali, endpoint interessati, intestazioni di richieste e risposte, frequenza di richieste stimata e dettagli sulla strategia della cache prima di contattare il supporto. Il risultato atteso è un record tecnico completo che supporta indagini più rapide. Verifica che le informazioni raccolte riflettano le richieste limitate e le condizioni in cui si verificano.
Se le risposte HTTP 429 - Troppe richieste continuano dopo la riduzione del volume delle richieste, il caching funziona come previsto, il comportamento dei tentativi è stato aggiornato e la limitazione è ancora ripetibile per gli stessi flussi di lavoro API, inviare un ticket al supporto Adobe e includere i timestamp, gli endpoint interessati, le intestazioni di richiesta e risposta, la frequenza stimata delle richieste e i dettagli della strategia della cache raccolti durante la risoluzione dei problemi.