cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: [DISCUSS} API Throttling minimum number of calls per unit of time
Date Sat, 02 Mar 2013 01:56:22 GMT
This is something that everyone writing plugins should think about.

A component being enabled does not automatically mean that functionality being enabled.  Here,
API Throttling component is enabled/disabled through componentcontext.xml  but the behavior
of whether it should automatically default to setting a limit on api calls is a property of
the api throttling component and should not depend on api throttling component being enabled/disabled
to set that limit.

It's a tricky problem to see because the distinction seems to be so small.  You have to look
at it from the perspective of the people who touches cloudstack's code.

One type of people is the distributor of CloudStack code.  He comes in and says I understand
CloudStack and I pick the best components to deploy it with.  For example, they may choose
to put in a different api throttling component to package.  He's the person who changes componentContext.xml.

Another type of people is the deployer of CloudStack code, usually a system admin.  He takes
the package from distributor and says I read the documentation and I understand how to use
your cloudstack  as a package.  He's the person who configures CloudStack through configuration

Sometimes, these two people are the same person but when we write code we have to think of
them as separate people.  Therefore, api throttling component should default to not limiting
api calls should not rely on the api throttling component being disabled in componentscontext.xml
to achieve that functionality.  That's functionality that belongs to api throttling after
it is enabled.

Just think of the case of the deployer upgrading.  The distributor decided they want to add
this functionality to the release but why should the deployer know that he should disable
api throttling in componentscontext.xml?


> -----Original Message-----
> From: Min Chen []
> Sent: Friday, March 1, 2013 4:39 PM
> To:
> Subject: Re: [DISCUSS} API Throttling minimum number of calls per unit of
> time
> Currently for 4.1 api throttling is enabled by default since we include that
> pluggable service in ComponentContext.xml. Parth, please file a defect for
> that, I will fix it.
> Thanks
> -min
> On 3/1/13 4:36 PM, "Parth Jagirdar" <> wrote:
> >That sounds right..
> >
> >If you enable throttling then .. you are assumed to know what it does.
> >If you enable throttling then .. you should decide values based on your
> >environment.
> >
> >Thanks,
> >.. Parth
> >
> >
> >-----Original Message-----
> >From: David Nalley []
> >Sent: Friday, March 01, 2013 2:58 PM
> >To:
> >Subject: Re: [DISCUSS} API Throttling minimum number of calls per unit
> >of time
> >
> >On Fri, Mar 1, 2013 at 5:34 PM, Parth Jagirdar
> ><> wrote:
> >> All,
> >>
> >> API throttling number can be set to anything at this point.
> >>
> >> Suggestions here is to have this number set to a value that is
> >>"greater than" number of API that can be fired by any potential action on
> UI.
> >>
> >> Minimum API for throttling that can be set  <  Number of API's Any
> >>action can fire in unit time.
> >> (unit time is 1 second)
> >>
> >>
> >> That said say action X fires 10 API in 2 seconds than having 10 as
> >>min number is safe. Or even 8 if we have decent idea of intervals
> >>they get fired at..
> >> But for action Y that fires 20 in 2 seconds with 15 in first seconds
> >>than 15 as min number is required to avoid undesirable effects
> >>
> >>
> >> Real life example,
> >>
> >> Login as user (not admin; throttling doesn't apply to Admin) fires
> >> about 8 in total. (in less than a second which is the unit we are
> >> using in API throttling)
> >>
> >> Now if this number is set to anything less than this will have
> >>unpleasant effect on UI.
> >>
> >> Including unwanted error (HTML 429) and partial UI screen rendering.
> >>
> >>
> >> So to hardcode numbers or just document and leave on admins to
> >>exercise cautions or ...  .. Please provide your suggestions /inputs.
> >>
> >> Track it here:
> >>
> >>
> >> Thanks,
> >> ...Parth
> >>
> >
> >IMO - people should not be surprised when they upgrade to a new feature
> >release.
> >The default should be no throttling.
> >We also have to remember that there are other things besides the UI
> >that interact with the API. If I were to use Cloudcat  or
> >knife-cloudstack and provision n-number of nodes, I suspect I'd rapidly
> >find myself throttled/blacklisted. Any sane default that's remotely
> >useful for most folks will be awful for high-end sophisticated users.
> >Adding new functionality that breaks things by default for folks is just a bad
> idea.
> >
> >
> >--David

View raw message