Spike Arrest Usage Question

[#1]

Hi ,

As per documentation of spike arrest policy documentation, the rates get smoothed ( http://docs.apigee.com/api-services/reference/spike-arrest-policy#howspikearrestworks )

So, even if we configure 1000ps as spike arrest number, we cannot have 2 concurrent requests, since each ms is assigned only one request and a second will be rejected.

Is this the expected behavior. It seems that this causes lot of false negatives.

Perhaps I am missing something. Appreciate any comments.

Thanks,

Jaskaran

[sabthar]

Hi Jaskarangump: Ideally yes - that's what the intention of having spike arrest rite. we dont want the heavy traffic reaches to our backend.

To achieve your requirement: Either you need to increase the spike arrest number or the MP(messageProcessor).

The SpikeArrest policy is at MP level. So if you have more than one MP(default 2 in Cloud) , then we can control the traffic accordingly.

Hope it helps.

[anilsr]

Great answer @Sabthar , +1

[#4]

Ok. This doesn't seem right. We don't want to increase the limit to an extremely large value because that defeats the purpose.

The statement that for a setting of 1000 ps which is reasonably high, we will never be able to support 2 requests concurrently seems pretty bad.

Regards,

Jaskaran

[chungss]

Hi all. We're facing similar issues where the argument was that if the Spike Arrest is set at 5ps, then 5 transactions should be allowed to go through, whether they're concurrent or "smoothen" across the second, as long as they're within the second.

Right now we're experiencing some possibilities that out of 5 transactions, only 4 of them go through simply because one of the request comes within 200ms of the previous transaction and got rejected because of the Spike Arrest policy.

Are there any options to work around this, other than having more MP?

[anilsr]

@Joseph Chung , Why can't you change the rate limit ?

[chungss]

Hi @Anil Sagar, thank you for the prompt response.

So, assuming my target backend can only handle 5tps, then it won't be wise to increase the Spike Arrest limit, right?

[kurtkanaskie]

To minimize concurrency issues you could try using the

<Identifier ref="client_id"/>

to uniquely identify and apply spike arrest against individual apps.

Also, seeing as you have a low per-second rate, you could try using a per-minute rate: 5ps = 300pm

[mipiace]

Does the per-minute rate have the same smoothing logic as the per-second rate albeit over a second interval? So 300pm would allow up to 5 requests per second, even concurrently, but would reject a 6th request received in the same second?

[dknezic]

No, if you're using Apigee X or Hybrid Spike Arrest with UseEffectiveCount set to true (regardless of time unit), it no longer performs smoothing and acts as a quota 

[mipiace]

Thanks @dknezic . Could you link to the docs that detail this behavior? All docs I've seen mention the smoothing algorithm.

[dknezic]

https://cloud.google.com/apigee/docs/api-platform/reference/policies/spike-arrest-policy#useeffectiv...

The lines against UseEffectiveCount true clarify it doesn't apply smoothing and if a burst of requests are sent they'll be accepted. Note this behavior is specific to X/Hybrid, not Edge or OPDK.

[mipiace]

Thanks @dknezic for that, I missed it. So to recap:

- In Apigee Edge the smoothing algorithm is always applied

- In Apigee X/Hybrid the smoothing algorithm applies only when UseEffectiveCount=false. When UseEffectiveCount=true, the spike arrest behaves like a quota policy.