incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [DISCUSS]API request throttling
Date Fri, 21 Dec 2012 19:04:28 GMT
The other usecase for throttling is during system instability and recovery
operations. E.g. Let's say there is maintenance going on in a part of the
cloud and so the operator knows that API requests are going to fail on the
backend / or create further pressure on the physical resources that they
cannot manage. In this case it is better to throttle the API requests
upfront. Requiring the admin to change a global setting via the DB does
not make sense: it has to be an admin API that can throttle everybody.

Which brings me to another question: what is the response: is it a HTTP
error code or a normal response that has to be parsed?
The reaction of most users to an error from the cloud is to re-try --
thereby making the problem worse.

On 12/20/12 10:10 AM, "Min Chen" <> wrote:

>That is a good thought. Currently we haven't thought of automatically
>trigger those blocked requests, and still expect users to manually trigger
>On 12/20/12 7:52 AM, "Pranav Saxena" <> wrote:
>>Amazon uses API throttling but from what I know they leverage the leaky
>>bucket algorithm and have some kind off  a "back-off" algorithm for few
>>of their tasks in which the API requests which were throttles are
>>automatically triggered depending upon what the use case is . Hence I
>>thought that perhaps , we might also encounter a similar scenario in
>>cloudstack as well . Can anyone think off a certain use case pertaining
>>to Cloudstack which might require such a functionality ?
>>-----Original Message-----
>>From: John Kinsella []
>>Sent: Thursday, December 20, 2012 9:05 PM
>>Subject: Re: [DISCUSS]API request throttling
>>On Dec 20, 2012, at 2:20 AM, Pranav Saxena <>
>> wrote:
>>> Also  are we planning to build the code in such a way that when we take
>>>into consideration the "throttling time "  , do we have some kind off a
>>>back-off algorithm to trigger the request again  automatically ( may be
>>>in some scenarios , not sure though ) , when we're being throttled (like
>>>come back after a "restore rate" period, specific to the type of API
>>>request one is making )  or the user has to make the request again
>>>manually every time once he is throttled.  This might sound vague but I
>>>am just curious to know if such a scenario can exist or not .
>>Good point.

View raw message