Hi Sanjeewa, On Fri, Apr 8, 2016 at 3:13 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> > > On Fri, Apr 8, 2016 at 3:09 PM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> Hi All, >> I'm writing this mail to give small update on current throttling feature >> implementation. >> After few iterations and implementations we tried to move throttle >> decision taking logic to handler itself to get better performance and >> reduce deployment complexity. >> Here i have listed some of the conception and implementation changes. >> >> Following are the throttling tiers users/administrators can define. >> >> - Resource level throttling tiers(API publisher can engage this to >> resource level when they create API). This will apply per resource level, >> per user or across all users. >> - Application level. When users create application then they can >> engage these tiers. This will apply per application per user base. >> - Subscription level. This will be applied when application developer >> subscribe to API. This will apply in per application, per API based. >> - Custom policies. These policies will define by administrator and >> apply to all API calls in system. Ex: Block some IP, limit number of >> requests from ip 1.1.1.1 to 100 per minute. We haven't finalized about >> this >> implementation.Application and subscription level throttling will remain >> same and only change for them is users can define bandwidth based policies >> for them. >> >> We are rethinking about application and subscriptions throttling tiers >> and new calculations may be based on following key template(comments, >> suggestions are welcome). >> >> - Resource Level throttle key : APIContext + Version + Resource + >> Http Verb + (throttlePolicy+Condition) +(user optional) >> - Subscription Level throttle key: applicationID + API Context + >> Version >> - Application Level Throttle key : ApplicationID + authz_user >> >> When users design APIs they can engage pre defined tiers at resource >> level as we had in earlier releases. But new addition is administrative >> user can design these tiers according to custom requirements. >> Users are allowed to define complex tiers with transport headers, IP >> address, query parameters and other attributes present in message context. >> One throttling policy may have different execution flow and each >> execution flow may have different conditions. >> > Can you elaborate more on what you mean by 'different execution flows'? My understanding is that a given throttling policy may have different conditions(user-agent, query params) and given API request will be applicable to n number of different policies. > >> When request dispatched to gateway as a part of resource data retrieving >> we will get throttling conditions from key manager side(what we had in >> database). Then we select matching throttling policy + conditions set and >> check they are on throttled key list. Then each gateway will perform >> throttling check locally. Data processing or decision making overhead will >> not add to this flow. >> >> After perform throttling all properties in message context will be pushed >> to global policy engine via thrift of binary protocol. Then global policy >> engine will evaluate them and update its in memory throttle decisions and >> write to database. Then these decisions will be available for new gateway >> instance to access via web service. Also decisions will be pushed to topic >> automatically. Then already started gateways will get updated >> decisions(Please refer attached digram). >> >> We ran few performance tests rounds and overnight tests on basic >> implementation(handler doing local throttling and push event). >> After some improvements we got following performance numbers. >> >> - Time to execute do throttle method including data publisher >> logic(complete throttling execute) : *0.05 to 0.08 Milli Seconds* >> - Time to execute throttling decision in level one : *0.003 Milli >> Seconds* (one level means application level, subscription or one >> resource pile line) >> - These numbers may change once we introduce custom policies. >> >> >> >> >> >> Thanks, >> sanjeewa. >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > -- Tishan Dahanayakage Software Engineer WSO2, Inc. Mobile:+94 716481328 Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, re-transmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
