incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pranav Saxena <>
Subject RE: [DISCUSS]API request throttling
Date Thu, 20 Dec 2012 10:20:50 GMT
+1 to what Nitin says . Global limits and flexibility to admin is something which is highly
desirable . 

It really gets interesting when you consider that you could further make decisions based on
parameters, such as a specific user and the application function when you consider throttling

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


-----Original Message-----
From: Nitin Mehta [] 
Sent: Thursday, December 20, 2012 3:04 PM
Subject: Re: [DISCUSS]API request throttling

On 20-Dec-2012, at 2:18 PM, Koushik Das wrote:

> +1 to the idea.
> Should there be some API to show how many API calls are remaining for a particular user
for the given interval? And should this call get counted as well? Currently in UI if you are
using wizard to deploy a VM multiple API calls are made but may not be obvious to the user.
If there is a limit then the number of exact API calls for each top level operation should
be clearly communicated to end user.

Good point. Currently UI uses list API, queryAsyncJob api's to fetch the progress of async
jobs and calls them every so often. 

> Should the API call limit be specific to roles available - normal user, domain admin,
root admin?

I believe besides having global limits, root admin should have the flexibility of changing
this just like we have it for other account limits like VMs, snapshots, templates he can create
etc. Admin would definitely want that flexibility.

> Thanks,
> Koushik
>> -----Original Message-----
>> From: Alex Huang []
>> Sent: Thursday, December 20, 2012 12:54 AM
>> To:
>> Subject: RE: [DISCUSS]API request throttling
>> The important part is the count is separated from other tables, which 
>> the spec specifies.  Then if we find problems we can.
>> --Alex
>>> -----Original Message-----
>>> From: Chiradeep Vittal []
>>> Sent: Wednesday, December 19, 2012 11:18 AM
>>> To: CloudStack DeveloperList
>>> Subject: Re: [DISCUSS]API request throttling
>>> I think the purpose of the DB is to support a clustered setup, 
>>> otherwise an in-memory counter would suffice.
>>> John's concern on DB performance is pertinent.
>>> I have had good success with MySQL's "UPDATE table SET 
>>> counter=counter+1"
>>> to increment counts, but that is specific to MySQL.
>>> Note that the FK is really not necessary -- you could ensure it is 
>>> deleted with a background task.
>>> This opensource project [1] prefers to use a Redis store to track 
>>> the counters to enable distributed counting, but I wonder if MySQL's 
>>> in-memory table would also work (there's a lot of limitations on the 
>>> in-memory store though).
>>> OTOH, a nosql store like Redis might find applications elsewhere.
>>> [1]
>>> On 12/19/12 11:01 AM, "John Kinsella" <> wrote:
>>>> Looks good - you got the one thing I would have thought of, to be 
>>>> able to throttle per account.
>>>> I'd suspect that tracking db counts in the db itself could cause a 
>>>> DOS, unless the inserts are buffered?
>>>> Also, how will the tracking work in clustered manager setups?
>>>> I don't know what this "campo" release is which the wiki page speaks of.
>>>> :)
>>>> On Dec 19, 2012, at 10:49 AM, Min Chen <>
>>>> wrote:
>>>>> Hi all,
>>>>> Currently, the legitimate users of CloudStack can occasionally 
>>>>> hammer the server with heavy API requests that cause undesirable 
>>>>> results, like killing the server, performance issues for other 
>>>>> CloudStack users. Also, it may become a mechanism for certain 
>>>>> malicious users to do malicious attacks to CloudStack service to 
>>>>> cause cloud outage. To prevent certain things happen, we would 
>>>>> like to introduce  API request throttling feature to limit number 
>>>>> of APIs that can be placed by each account within certain time 
>>>>> duration and will block API requests if the account is over the 
>>>>> limit so that he/she have to retry later. The detailed FS can be 
>>>>> found at
>>> Thrott
>>>>> ling.
>>>>> Please let me know any comments and suggestions.
>>>>> Thanks
>>>>> -min
>>>> Stratosec - Secure Infrastructure as a Service
>>>> o: 415.315.9385
>>>> @johnlkinsella

View raw message