Spike Arrest - requests per minute behaviour

[#1]

In apigee edge we have a proxy with the spike arrest set at 60pm and so expected a limit of 2 requests per second across both message processors. We have an application which sends a batch of 11 concurrent requests and we are seeing all 11 requests sent to the target over 2 seconds instead of 4 getting through and the rest getting stopped by spike arrest. Are there any explanations why the limit may not behaving as expected ?

Thanks very much

Steve

[anilsr]

Dear @Stephen Jones , Welcome to Apigee Community.

Yes, Ideally it should limit. Can you post your spike arrest policy xml ?

[#3]

This is the policy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArrest.Unpack">
    <DisplayName>SpikeArrest.Unpack</DisplayName>
    <FaultRules/>
    <Properties/>
    <Rate ref="flow.glh.configuration.unpackSpikeRate"/>
</SpikeArrest>

The actual rate is derived from a flow variable which is set to '60pm'.

[gaurav_bhandari]

@Stephen Jones

Can you do few more test like changing the value to 1PM, 1PS?

1PS is basically 1 request in 1000 ms.

[anilsr]

@Stephen Jones , Can you verify using trace that flow variable is getting populated as expected in above policy ? 60pm should work. Change it to lower value like 6pm to verify using browser. Let us know if any.

[#6]

Couple of things here

1. Check in trace to make sure the flow is hitting spike arrest policy

2. Check to make sure the flow variable is populated

3. For debugging purposes, hard code the value of 60pm in the spike arrest policy to see if that works

4. Try reducing the value to a lower number and hit it with postman requests

[sunandita_dam]

@Stephen Jones

Checking the value of below mentioned flow variables should be helpful:

Variable	Type	Permission	Description
ratelimit.{policy_name}.allowed.count	Long	Read-Only	Returns the allowed limit count
ratelimit.{policy_name}.used.count	Long	Read-Only	Returns the limit used in the counter
ratelimit.{policy_name}.exceed.count	Long	Read-Only	Returns the count exceeds the limit in the current counter
ratelimit.{policy_name}.expiry.time	Long	Read-Only	Returns the time in milliseconds based on which the limit expires and new counter starts

[#8]

Thanks very much for the suggestions. Generally in testing when we use a per second limit it seems to be working but the per minute limits do not. I have been testing the proxy and spike arrest using the trace tool and I can verify that the variables are being populated correctly and that the behaviour is the same if I pick up the spike value from a variable or have it specified directly in the spike policy. Looking at the flow variables in trace however the ratelimit.SpikeArrest.Unpack.expiry.time is always 0 which would imply that each request is effectively in its own time interval. The variables are (for a 60pm rate setting)

ratelimit.SpikeArrest.Unpack.allowed.count	60
ratelimit.SpikeArrest.Unpack.available.count	58
ratelimit.SpikeArrest.Unpack.class.allowed.count	0
ratelimit.SpikeArrest.Unpack.class.available.count	0
ratelimit.SpikeArrest.Unpack.class.exceed.count	0
ratelimit.SpikeArrest.Unpack.class.total.exceed.count	0
ratelimit.SpikeArrest.Unpack.class.used.count	0
ratelimit.SpikeArrest.Unpack.datastore.fail.open	false
ratelimit.SpikeArrest.Unpack.exceed.count	0
ratelimit.SpikeArrest.Unpack.expiry.time	0
ratelimit.SpikeArrest.Unpack.failed	false

Running the trace with the rate set to 35ps where the spike arrest policy limit is working and rejecting requests also shows a value of 0 for the ratelimit.SpikeArrest.Unpack.expiry.time