IS THERE ANY ORDER FOR THESE POLICIES (SPIKE ARREST,QUOTA AND CONCURRENT POLICY) IN TERMS OF BETTER PERFORMANCE OR SECURITY ?
OR WHAT WILL BE THE BEST ORDER TO ADD THESE POLICIES?
Hi @Arun Prasath Sivanesan, please have a look at this doc, which compares all three policies.
IMO security wise I would first control the number of calls made & then check if the user/developer quota & finally use concurrent rate limit.
Spike Arrest >> Quota on Proxyendpoint Preflow
Use Concurrent Rate Limit on Targetendpoint.
Note - Use of the Concurrent Rate Limit policy is known to impact performance and will result in lower throughputs.
@Siddharth Barahalikar , Agree with performance impact of Concurrent Rate Limit.
Regarding Order, What if quota is calculated, concurrent rate limit raises exception ? See my answer below, Let me know what you think !
You don't want to count the quota before this policy if concurrent rate limit raises exception.
Thanks, @Anil Sagar @ Google for pointing it out, I missed this point while answering. Now it makes sense why we need to use quota after concurrent policy.
So, in this case, we should be adding Quota on Target Endpoint Preflow after Concurrent Policy right?
If yes, then the proxy is going to execute all policies attached on Proxyendpoint Preflow >> ConditionalFlow >> PostFlow Requests and will check for Quota only on Targetendpoint Preflow after Concurrent Policy.
Is this one of the reasons why Concurrent Rate Limit policy is known to impact performance and will result in lower throughputs?
Great Question @Arun Prasath Sivanesan , Great Question,
Here is what i think about same in terms of order,
Hope it helps.
If I am not wrong, concurrent rate policy should be attached to target endpoint (also default fault rule) whereas spike arrest and quota should be attached to proxy end point. So I believe the first in the order should be spike arrest and then quota after eliminating concurrent from proxy endpoint.
correct me if I am wrong
User | Count |
---|---|
7 | |
2 | |
2 | |
1 | |
1 |