Hi Sanjeewa, Would like to get some clarifications.
1) What happens when this spike arrest limit exceeds? Does it terminate the request and how does it propagates to the requester? 2) Can this be used as a notification method instead and notify relevant party instead of blocking the request which in future can be associated with a manual blocking if its a malicious act? In that case if will be kind of a warning type but will allow to bypass the request. Not sure whether this is a valid usecase though. Correct me if I am wrong. 3) How do we deal with concurrent connections? Are we gonna address concurrent rate limits with this? 4) Does this calculation happens from the last request received or every x interval of time? 5) Can someone customize the rate limit workflow as in quota? Regards, Dilshan On 26 April 2016 at 22:01, Sanjeewa Malalgoda <[email protected]> wrote: > Hi All, > While working on recent throttling improvements we decided to add spike > arrest(block sudden api call burts) support for API Manager. > With this users will be able to add subscription level policies with spike > arrest policies. > > Requirement: > While doing throttling for certain subscriptions we may need to block > number of requests coming at a given time(Ex number of requests per second > or minute). > When we have subscription level policy for longer periods, sometimes we do > not need to let users to consume all of allocated quata at one time. > Also with this kind of implementations we can handle sudden spikes and > attacks coming from users. > Since subscription is more like a business level relationship we decided > to add this to subscription level first. > > Solution, > We are planning to define spike arrest policy when users create > subscription level tier. > Then we will create WS policy on demand for given subscription level > throttle key. > Then calculate request count and perform throttling at node level. > We will show tool tip or notification saying this will apply at node level > and in distributed deployment count may depend on number of instances. > Since admin users define these policies end users do not need to > understand this complexity(they see subscription level policy with spike > arrest policy and use it). > > Limitations. > If we go for new throttling implementation with siddhi we may not be able > to get very accurate results as we need to publish all events in cluster. > So we thought of doing this with local node and old throttling > implementation. > That implementation was very accurate for this kind of use cases. Reason > for that is nodes can take local decisions. > Another limitation was this count and throttling happen at local node > level. If we enabled clustering then anyway counters will replicate and we > can got for cluster wide count. > > > Please refer below image of subscription level policy editor. As you can > see users can define spike arrest policy when they define subscription > level policy. > > > > > > Please review this and share your thoughts. > > Thanks, > sanjeewa. > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
