Hi Nuwan,
On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias <[email protected]> wrote: > This design brings on a hard (mandatory) dependency to the registry from > the API Gateway right? If each API is to have its own policy definition, > the publisher and gateway must connect to a single registry. This will > cause problems in some deployment patterns which have the Gateway in DMZ > and publisher in the LAN. Can our throttling engine work if we just feed it > the request count and unit time without feeding it a policy definition? > Not in a very straightforward way. The API exposed by throttle.core only allows passing ThrottleContext, a key and the Tier name. When going through the usages of ThrottleContext it seems that it can only be created out from a policy file. But need to check if it's possible to create ThrottleContext only using unit time and MaxRequest count. > If that works then we can survive without the registry for this. > Another option is to use the same tiers.xml that is being used for other throttling cases and refer to a role defined there. If needed to update/add a new tier it will have to be done through tier edit UI. Even with this approach, the problem won't be completely solved. > > Why would we need a new handler? What would be the drawbacks of using the > existing handler? > We can use the existing one. > > The location to get the limit would be on the API Implement section IMO. > > Thanks, > NuwanD. > > On Tue, Sep 8, 2015 at 9:40 PM, Amila De Silva <[email protected]> wrote: > >> Hi, >> >> Current Throttling capabilities of API Manager only allows defining user >> wise and Application wise Access Quotas. >> >> >> For example when considering an Application and a set of APIs Subscribed, >> like below (tier limit is shown next to the API) >> >> Application-1 (1000 Req/min) >> | >> +-+API-1 (10 Req/min) >> | >> +-+API-2 (1 Req/min) >> | >> +-+API-3 (5 Req/min) >> >> each new token would allow end-users to make the number of requests >> defined by the tier. Using a token generated for Application-1, API1 can be >> invoked at a rate of 10 Req/min, API-2 - 1Req/min and likewise. So when a >> new user signs in, there'd be a potential increase in the traffic on the >> API. >> >> As of now there isn't a way to limit the total number of calls made on an >> API. Tiers defined at the API Level, doesn't reflect the global limit of >> the backend; which means that, as an API keeps gathering users, hits on the >> Backend would also keep increasing without being controlled. >> >> With API Manager 1.10.0, the plan is to provide the capability to define >> Hard Throttling limits for APIs. The limit will be defined per API basis, >> and this usually will reflect the number of requests the actual backend can >> handle. >> >> This feature warrants several changes on API Designing UI, and those can >> be discussed in detail in mails to follow. >> >> If giving a high level idea about the flow. >> 1. API creator logs into the publisher and creates an API. >> 2. API Creator enables Hard Limit throttling for the API. >> 3. Number of requests allowed and Unit Time is specified. >> 4. Changes are saved and Published to the Gateway. >> >> When saving the API, a throttling policy specific to the API will be >> created and saved in the registry. >> >> For enforcing throttling limit, a new handler will be written, which >> would only appear for those APIs on which Hard limit is enabled. The >> handler would refer to the policy saved to the registry and would apply the >> limit defined. >> >> Please share your thoughts on this. >> >> -- >> *Amila De Silva* >> >> WSO2 Inc. >> mobile :(+94) 775119302 >> >> > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
