On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva <ami...@wso2.com> wrote:
> > On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda <sanje...@wso2.com> > wrote: > >> I also believe we should use existing handler without writing new one. >> >> And regarding registry decoupling, publisher may be able to push API to >> gateway as we do now. >> And just before we call rest API admin service we may call registry admin >> service(may be we need to write simple service for this as flow continue >> with super admin - super tenant deployed multi tenanted service) and push >> tiers.xml file. >> With that we may keep registry separation between gateway and publisher. >> That would be valuable when we have MZ and DMZ pattern and gateway in DMZ. >> >> Thanks, >> sanjeewa. >> >> >> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva <ami...@wso2.com> wrote: >> >>> Hi Nuwan, >>> >>> >>> >>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias <nuw...@wso2.com> 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. >>>> >>> We can keep max request count and unit time in the API itself. While > initialising the APIThrottleHandler, a policy.xml has to be created out of > these values and the generated policy will be used to create the > ThrottleContext. Dynamic policy won't be stored anywhere, so when moving > the API from one environment to another, there won't be a risk of losing > anything. > > For the scope of this feature, should be consider about providing > capability to specify hard throttling limits per each resource verb > combination. > Accidentally sent the mail halfway :) What I was going to highlight was need of having different hard limits for each resource + verb combination. Not every resource of an API, consume the same amount of server resources. For example, when sending response to an OPTIONS call, the backend might be sending a cached (or a static) response, whilst when responding to a POST, it might be doing several DB calls back and forth. Actually, it might be an overflow of POST requests that can take the back-end down. So while specifying a quota, heavy weight resources should be given less quota, and lightweight (but more frequently accessed resources) should be given a higher quota. 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 <ami...@wso2.com> 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 : nuw...@wso2.com >>>> Phone : +94 777 775 729 >>>> >>> >>> >>> >>> -- >>> *Amila De Silva* >>> >>> WSO2 Inc. >>> mobile :(+94) 775119302 >>> >>> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > *Amila De Silva* > > WSO2 Inc. > mobile :(+94) 775119302 > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
