incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: [DISCUSS} API Throttling minimum number of calls per unit of time
Date Tue, 05 Mar 2013 17:53:57 GMT
This issue has been fixed in both 4.1 and master. A new global setting
"api.throttling.enabled" is introduced.
By default, it is set to false, so no API throttling is enabled. To enable
it, just change the setting to true, and restart MS. FS is also updated
with this information.

Thanks
-min

On 3/1/13 6:06 PM, "Min Chen" <min.chen@citrix.com> wrote:

>Thanks Alex for clarification. I will provide an extra global setting to
>allow user to easily enable/disable this instead of going through
>componentContext.xml. Parth already filed a bug to track this:
>https://issues.apache.org/jira/browse/CLOUDSTACK-1484
>
>-min
>
>On 3/1/13 5:56 PM, "Alex Huang" <Alex.Huang@citrix.com> wrote:
>
>>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
>>variables.
>>
>>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?
>>
>>--Alex
>>
>>
>>
>>> -----Original Message-----
>>> From: Min Chen [mailto:min.chen@citrix.com]
>>> Sent: Friday, March 1, 2013 4:39 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> 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" <Parth.Jagirdar@citrix.com> 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 [mailto:david@gnsa.us]
>>> >Sent: Friday, March 01, 2013 2:58 PM
>>> >To: cloudstack-dev@incubator.apache.org
>>> >Subject: Re: [DISCUSS} API Throttling minimum number of calls per unit
>>> >of time
>>> >
>>> >On Fri, Mar 1, 2013 at 5:34 PM, Parth Jagirdar
>>> ><Parth.Jagirdar@citrix.com> 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:
>>>https://issues.apache.org/jira/browse/CLOUDSTACK-1483
>>> >>
>>> >>
>>> >> 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
>>
>


Mime
View raw message