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 offre due criteri che consentono di ottimizzare la gestione del traffico ridurre al minimo la latenza per le app mantenendo 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.

Queste norme devono essere utilizzata per prevenire improvvisi burst di traffico causati da malintenzionati che tentano di interrompere un servizio mediante un attacco DoS (Denial of Service) o applicazioni client con bug.

Vedi SpikeArrest .

Criteri per le quote

Questo criterio applica i 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, app, sviluppatori, chiavi API, token di accesso e così via. Di solito, le chiavi API vengono utilizzate identificare le app client. Questo criterio è costoso dal punto di vista del calcolo, quindi per le API a traffico elevato deve essere configurata per intervalli di tempo più lunghi, ad esempio un giorno o un mese. È necessario utilizzare questo criterio per applicare contratti aziendali o SLA (accordi sul livello del servizio) con sviluppatori e partner, anziché per la gestione del traffico.

Consulta i criteri per le quote.