Why You Need It

Compare Quota Policy

Syntax

The<SpikeArrest> element uses the following syntax:

<SpikeArrestcontinueOnError="[false|true]"enabled="[true|false]"name="policy_name"><DisplayName>display_name</DisplayName><Properties/><Identifierref="flow_variable"/><MessageWeightref="flow_variable"/><Rateref="flow_variable">rate[pm|ps]</Rate><UseEffectiveCount>[false|true]</UseEffectiveCount></SpikeArrest>

Default Policy

The following example shows the default settings when you add a SpikeArrest policy to your flow in the UI:

<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>

Example 1

The following example sets the rate to five per second:

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

This sample policy allows a maximum of 5 requests per second. Via smoothing, it is enforced as a maximum of one request for every 200millisecond (1000/5) interval.

Example 2

The following example sets the rate to 12 per minute:

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

This sample policy allows a maximum of 12 requests per minute at the rate of one request per 5second (60/12) interval. If there is more than one request in the 5second interval, such requests are allowed (no smoothing) provided the number of requests is less than the configured rate limit of 12 per minute.

Example 3

The following example restricts requests to 12 per minute (one request allowed every five seconds, or 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 addition, the<MessageWeight> element accepts a custom value (theweight header) that adjusts message weights for specific apps or clients. This provides additional control over throttling for entities that are identified with the<Identifier> element.

Example 4

The following example instructs SpikeArrest to look for a runtime value set via the request that is passed in as therequest.header.runtime_rate flow variable:

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

The value of the flow variable must be in the form ofintpm orintps.

To try this example, execute a request like the following:

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

Syntax

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

Example

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

Syntax

<SpikeArrestcontinueOnError="[false|true]"enabled="[true|false]"name="policy_name"><Identifierref="flow_variable"/></SpikeArrest>

Example 1

The following example applies the SpikeArrest policy per developer ID:

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

Syntax

<SpikeArrestcontinueOnError="[false|true]"enabled="[true|false]"name="policy_name"><MessageWeightref="flow_variable"/></SpikeArrest>

Example 1

The following example restricts requests to 12 per minute (one request allowed every five seconds, or 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 this example,<MessageWeight> accepts a custom value (theweight header in the request) that adjusts message weights for specific clients. This provides additional control over throttling for entities that are identified with the<Identifier> element.

Syntax

You can specify rates in one of the following ways:

• A static rate that you specify as the body of the<Rate> element
• A variable value, which can be passed by the client; identify the name of the flow variable using theref attribute

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

Valid rate values (either defined as a variable value or in the body of the element) must conform to the following format:

• intps (number of requests per second, smoothed into intervals of milliseconds)
• intpm (number of requests per minute, smoothed into intervals of seconds)

The value ofint must be a positive, non-zero integer.

Example 1

The following example sets the rate to five requests per second:

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

The policy smoothes the rate to one request allowed every 200milliseconds (1000/5).

Example 2

The following example sets the rate to 12 requests per minute:

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

This example policy smoothes the rate to one request allowed every fiveseconds (60/12).

If set totrue, SpikeArrest is distributed in a region. That means request counts are synchronized across message processors (MPs) in a region. In addition, a "sliding window" rate limiting algorithm is employed. This algorithm provides consistent rate limit behavior and does not "smooth" the number of incoming requests that can be sent to the backend. If a burst of requests are sent in a short time interval, they are allowed as long as they do not exceed the configured rate limit, as set in the<Rate> element. For example:

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

false (default)

If set tofalse (the default), the SpikeArrest policy uses a "token bucket" algorithm that smooths traffic spikes by dividing the rate limit that you specify into smaller intervals. A drawback of this approach is that multiple legitimate requests coming in over a short time interval can potentially be denied.

For example, say you enter a rate of 30pm (30 requests per minute). In testing, you might think you could send 30 requests in 1 second, as long as they came within a minute. But that's not how the policy enforces the setting. If you think about it, 30 requests inside a 1-second period could be considered a mini spike in some environments.

• Per-minute rates get smoothed into full requests allowed in intervals ofseconds.
  

  For example, 30pm gets smoothed like this:
  60 seconds (1 minute) / 30pm = 2-second intervals, or 1 request allowed every 2 seconds. A second request inside of 2 seconds will fail. Also, a 31st request within a minute will fail.

• Per-second rates get smoothed into full requests allowed in intervals ofmilliseconds.

  For example, 10ps gets smoothed like this:
  1000 milliseconds (1 second) / 10ps = 100-millisecond intervals, or 1 request allowed every 100 milliseconds. A second request inside of 100ms will fail. Also, an 11th request within a second will fail.