Limitazione di frequenza

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Per mantenere le prestazioni e la disponibilità su una base diversificata di app client, è fondamentale per mantenere il traffico delle app entro i limiti della capacità delle API e dei servizi di backend. È per fare in modo che le app non consumino più risorse di quelle consentite.

Apigee fornisce due criteri che ti consentono di ottimizzare la gestione del traffico per minimizzare la latenza per le app, mantenendo al contempo l'integrità dei servizi di backend. Ogni tipo di criterio indirizza un aspetto distinto della gestione del traffico. In alcuni casi, è possibile utilizzare sia i criteri in un singolo proxy API.

Criterio di SpikeArrest

Il criterio SpikeArrest protegge dai picchi di traffico. Questo che limita il numero di richieste elaborate da un proxy API e inviate a un backend, per una protezione contro tempi di inattività e ritardi delle prestazioni.

Questo criterio deve essere utilizzato per impedire picchi improvvisi di traffico causati da utenti malintenzionati che tentano di interrompere un servizio utilizzando un attacco denial-of-service (DoS) o da applicazioni client con bug.

Vedi SpikeArrest .

Criteri per le quote

Questo criterio applica limiti di consumo alle app client mantenendo un "contatore" distribuito che conteggia le richieste in arrivo. Il contatore può conteggiare le chiamate API per qualsiasi entità identificabile, tra cui app, sviluppatori, chiavi API, token di accesso e così via. Di solito, le chiavi API vengono utilizzate identificare le app client. Questo criterio è dispendioso in termini di risorse di calcolo, pertanto per le API con traffico elevato deve essere configurato per intervalli di tempo più lunghi, ad esempio un giorno o un mese. Queste norme devono essere utilizzate per applicare contratti commerciali o SLA con sviluppatori e partner, anziché per la gestione del traffico operativo.

Consulta i criteri per le quote.