Spike Arrest Policy

Google Cloud Apigee
1

Hello,

I have a doubt regarding SpikeArrest policy within Apigee X, and I would like to ask you for help.
I’ve prepared a really easy example, as shown below:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest continueOnError="false" enabled="true" name="SA-SpikeArrest">
  <DisplayName>SA-SpikeArrest</DisplayName>
  <Properties/>
  <Rate>4pm</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

then I’ve attached it to API proxy, which is only used by me, and those are my observations:

  1. I was able to do more than 4 requests in one minute, it was possible to do about 6 or more
  2. According to the documentation Spike Arrest Policy should automatically smooth the traffic, so for example if rate is set to 4pm then it means it should be allowed to perform 1 request per 15 seconds. During my tests I could do all 4 requests in first 5 seconds, and moreover after 30 seconds it was possible to do even more requests

Is anyone able to explain, why does it work in such unexpected way ? Am I doing something wrong ?

Thanks

2

Hi Mateusz,

Look at the UseEffectiveCount element. By default, the value is false, so the SpikeArrest is not distributed for the region. Each message processor keeps its own record of the last time a matching request was received. It is likely you hit multiple message processors with your requests. With more than one message processor, you will likely allow more requests than the configured rate would lead you to expect.

If you set UseEffectiveCount to true, the count should be shared among the message processors, and you will likely see the pattern you expect. Setting this to true does cause the spike arrest processing to be a little less efficent.

3

Hello mdunker,

Yes, I have UseEffectiveCount set to true, but still it lives it’s own life.
Any other suggestions ?

4

Other than thinking about whether a quota is better for your use case, not really.

To get more information about how the requests are being handled, I recommend looking at the system.uuid flow variable in your tests to see which message processor is handling each request (and how many message processors are active for you). Maybe you can figure something out from that.

5

Also, this response is useful for understanding how spike arrests work (at least the last time I checked): Spike Arrest policy | Behavior issue - #3 by rabustamante