Sorry, please ignore that release name, already updated wiki for that.

Your feedback of concern of frequent db operations is very good. That is
why currently I totally isolate this count data in a separate table to
facilitate us to easily tune this specific data.
If we see a big issue in this table update or query, we have several
alternative thoughts in mind to explore, for example, using mysql in
memory table, memcache or ehcache, etc.

Regarding clustered manager setup question, I had thought about that, that
is why I have used db table to track count.

Thanks
-min


On 12/19/12 11:01 AM, "John Kinsella" <[email protected]> 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 <[email protected]>
> 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 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+Request+Thrott
>>ling.
>> 
>> Please let me know any comments and suggestions.
>> 
>> Thanks
>> -min
>
>Stratosec - Secure Infrastructure as a Service
>o: 415.315.9385
>@johnlkinsella
>

Reply via email to