We would like to seek clarification regarding the Spike Arrest policy behavior observed in our environment.
Configuration Details:
Spike Arrest Rate: 300 PM (per minute)
EffectiveCount: true
Number of Message Processors (MPs): 4
Expected Behavior As per our understanding, 300 PM should be smoothed at the seconds level. Hence, we expect approximately 5 requests per 4 seconds to be allowed across the organization when effectiveCount is enabled as true.
Observed Behavior: During burst testing, we observed that up to 32 requests are getting allowed within a short interval, which is higher than the expected smoothed rate.
As per Apigee documentation, the bucket size is configured as 10% of messagesPerPeriod. Based on this, we would like confirmation on the below understanding:
1- Whether the bucket size is allocated at the beginning of the each interval in this case : 4 mins.
2: Whether the bucket gets refilled only after being exhausted or any interval without waiting for exhausted.
Whether token refill happens approximately every 800 milliseconds on each MP.
Whether after completion of the full interval, the bucket is reallocated with approximately 7.5 tokens per MP (considering effective distribution across 4 MPs).
Could you please confirm if our understanding is correct and help explain the reason behind allowing up to 32 requests during burst scenarios?
Please let us know if you need any additional logs, trace sessions, or configuration details from our side.
tl:dr - your understanding of how this works is correct.
Good question and good job of understanding how the Spike Arrest algorithm works. Based on your question and reference to the documentation I’m assuming you are using Apigee Edge or OPDK. The behavior of the policy works differently in Apigee X / hybrid. For reference below are the links to the relevant documentation.
To answer your specific questions. Using the bucket algorithm here will cause a quick burst to be allowed at a somewhat faster rate than you would expect, especially if you are going from no traffic to a spike. You have correctly estimated the approximate rate of allowed traffic as 5 requests per 4 seconds for each MP (multiplied by 4 MPs this would give you your rate across the entire org of course).
The bucket will be “filled” when the spike arrest policy is deployed / gets its configuration. Note that the bucket at that point will have some number available likely close to the 10% number you mention that could be used immediately.
As you have observed, when you first hit the system, you can exceed the capacity, but with continued traffic the Spike Arrest should smooth traffic close to the rate you selected.
As for filling the bucket, it will get filled at the rate you have set. In your example, this is approximately with one entry every second for each MP. The filling will continue at this rate until it has reached its “capacity”, again approximately 10% of the overall limit.
You can see that this means if you are using it at less than capacity, it could allow short spikes of requests coming faster than the overall limit.
