Criterio SpikeArrest

Perché è necessario

Confrontare i criteri per le quote

Sintassi

L'elemento <SpikeArrest> utilizza la seguente sintassi:

<SpikeArrest   continueOnError="[false|true]"   enabled="[true|false]"   name="policy_name" >   <DisplayName>display_name</DisplayName>   <Properties/>   <Identifier ref="flow_variable"/>   <MessageWeight ref="flow_variable"/>   <Rate ref="flow_variable">rate[pm|ps]</Rate>   <UseEffectiveCount>[false|true]</UseEffectiveCount> </SpikeArrest>

Norme predefinite

L'esempio seguente mostra le impostazioni predefinite quando aggiungi un criterio SpikeArrest al tuo flusso nell'interfaccia utente:

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">   <DisplayName>Spike Arrest-1</DisplayName>   <Properties/>   <Identifier ref="request.header.some-header-name"/>   <MessageWeight ref="request.header.weight"/>   <Rate>30ps</Rate>   <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>

Esempio 1

L'esempio seguente imposta la frequenza su cinque al secondo:

<SpikeArrest name="SA-Static-5ps">   <Rate>5ps</Rate>   <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>

Questo criterio di esempio consente un massimo di 5 richieste al secondo. Tramite lo smoothing, viene applicato un massimo di una richiesta ogni 200 millisecondi (intervallo di 1000/5).

Esempio 2

L'esempio seguente imposta la frequenza su 12 al minuto:

<SpikeArrest name="SA-Static-12pm">   <Rate>12pm</Rate>   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

Questa policy di esempio consente un massimo di 12 richieste al minuto alla velocità di una richiesta ogni 5 secondi (60/12). Se nell'intervallo di 5 secondi sono presenti più richieste, queste sono consentite (nessun livellamento) a condizione che il numero di richieste sia inferiore al limite di frequenza configurato di 12 al minuto.

Esempio 3

L'esempio seguente limita le richieste a 12 al minuto (una richiesta consentita ogni cinque secondi o 60/12):

<SpikeArrest name="SA-With-Dynamic-Weight-1">   <Rate>12pm</Rate>   <Identifier ref="client_id" />   <MessageWeight ref="request_specific_weight" />   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

Inoltre, l'elemento <MessageWeight> accetta un valore personalizzato (l'intestazione weight) che regola i pesi dei messaggi per app o client specifici. Ciò fornisce un controllo aggiuntivo sulla limitazione per le entità identificate con l'elemento <Identifier>.

Esempio 4

L'esempio seguente indica a SpikeArrest di cercare un valore di runtime impostato tramite la richiesta passata come variabile di flusso request.header.runtime_rate:

<SpikeArrest name="SA-From-Inbound-Header-1">   <Rate ref="request.header.runtime_rate" />   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

Il valore della variabile di flusso deve essere nel formato intpm o intps.

Per provare questo esempio, esegui una richiesta come la seguente:

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

Sintassi

<PolicyElement>   <DisplayName>POLICY_DISPLAY_NAME</DisplayName>   ... </PolicyElement>

Esempio

<PolicyElement>   <DisplayName>My Validation Policy</DisplayName> </PolicyElement>

Sintassi

<SpikeArrest   continueOnError="[false|true]"   enabled="[true|false]"   name="policy_name" >   <Identifier ref="flow_variable"/> </SpikeArrest>         

Esempio 1

Il seguente esempio applica il criterio SpikeArrest per ID sviluppatore:

<SpikeArrest name="Spike-Arrest-1">   <Identifier ref="developer.id"/>   <Rate>42pm</Rate/>   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

Sintassi

<SpikeArrest   continueOnError="[false|true]"   enabled="[true|false]"   name="policy_name" >   <MessageWeight ref="flow_variable"/> </SpikeArrest>

Esempio 1

L'esempio seguente limita le richieste a 12 al minuto (una richiesta consentita ogni cinque secondi o 60/12):

<SpikeArrest name="SA-With-Dynamic-Weight-1">   <Rate>12pm</Rate>   <Identifier ref="client_id" />   <MessageWeight ref="request_specific_weight" />   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

In questo esempio, <MessageWeight> accetta un valore personalizzato (l'intestazione weight nella richiesta) che regola i pesi dei messaggi per client specifici. Ciò fornisce un controllo aggiuntivo sulla limitazione per le entità identificate con l'elemento <Identifier>.

Sintassi

Puoi specificare le tariffe in uno dei seguenti modi:

• Una tariffa statica che specifichi come corpo dell'elemento <Rate>
• Un valore variabile, che può essere passato dal client; identifica il nome della variabile di flusso utilizzando l'attributo ref

<SpikeArrest   continueOnError="[false|true]"   enabled="[true|false]"   name="policy_name" >   <Rate ref="flow_variable">rate[pm|ps]</Rate> </SpikeArrest>

I valori di tasso validi (definiti come valore di variabile o nel corpo dell'elemento) devono rispettare il seguente formato:

• intps (numero di richieste al secondo, suddivise in intervalli di millisecondi)
• intpm (numero di richieste al minuto, uniformato in intervalli di secondi)

Il valore di int deve essere un numero intero positivo diverso da zero.

Esempio 1

L'esempio seguente imposta la frequenza su cinque richieste al secondo:

<SpikeArrest name="SA-Static-5ps">   <Rate>5ps</Rate>   <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>

Il criterio uniforma la velocità a una richiesta consentita ogni 200 millisecondi (1000/5).

Esempio 2

L'esempio seguente imposta la velocità a 12 richieste al minuto:

<SpikeArrest name="SA-Static-12pm">   <Rate>12pm</Rate>   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

Questa norma di esempio uniforma la frequenza a una richiesta consentita ogni cinque secondi (60/12).

true

Se impostato su true, SpikeArrest viene distribuito in una regione. Ciò significa che i conteggi delle richieste vengono sincronizzati tra i processori di messaggi (MP) in una regione. Inoltre, viene utilizzato un algoritmo di limitazione di frequenza "a finestra scorrevole". Questo algoritmo fornisce un comportamento coerente del limite di frequenza e non "uniforma" il numero di richieste in entrata che possono essere inviate al backend. Se viene inviato un burst di richieste in un breve intervallo di tempo, queste sono consentite a condizione che non superino il limite di frequenza configurato, come impostato nell'elemento <Rate>. Ad esempio:

<SpikeArrest name="Spike-Arrest-1">   <Rate>12pm</Rate>   <Identifier ref="client_id" />   <MessageWeight ref="request.header.weight" />   <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

false (impostazione predefinita)

Se impostato su false (valore predefinito), il criterio Spike Arrest utilizza un algoritmo "token bucket" che attenua i picchi di traffico dividendo il limite di frequenza specificato in intervalli più piccoli. Uno svantaggio di questo approccio è che più richieste legittime ricevute in un breve intervallo di tempo possono potenzialmente essere rifiutate.

Ad esempio, supponiamo che tu inserisca una frequenza di 30 pm (30 richieste al minuto). Durante il test, potresti pensare di poter inviare 30 richieste in 1 secondo, purché rientrino in un minuto. Tuttavia, non è così che la norma applica l'impostazione. Se ci pensi, 30 richieste in un periodo di 1 secondo potrebbero essere considerate un mini picco in alcuni ambienti.

• Le tariffe al minuto vengono uniformate in richieste complete consentite a intervalli di secondi.
  

  Ad esempio, 30pm viene uniformato in questo modo:
  60 secondi (1 minuto) / 30pm = intervalli di 2 secondi o 1 richiesta consentita ogni 2 secondi. Una seconda richiesta entro 2 secondi non andrà a buon fine. Inoltre, una 31ª richiesta entro un minuto non andrà a buon fine.

• Le tariffe al secondo vengono uniformate in richieste complete consentite a intervalli di millisecondi.

  Ad esempio, 10ps viene uniformato in questo modo:
  1000 millisecondi (1 secondo) / 10ps = intervalli di 100 millisecondi o 1 richiesta consentita ogni 100 millisecondi. Una seconda richiesta entro 100 ms non andrà a buon fine. Inoltre, l'undicesima richiesta entro un secondo non andrà a buon fine.