incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sowmya Krishnan <sowmya.krish...@citrix.com>
Subject RE: [DISCUSS]API request throttling
Date Fri, 01 Feb 2013 04:23:39 GMT
Sorry...I should've been more clear. My question here is, from the UI, when a user fires an
async job, do the queryAsyncJobResult APIs also get counted? 

-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com] 
Sent: Friday, February 01, 2013 4:44 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS]API request throttling

I think she's talking about the CloudStack UI

On 1/31/13 2:03 PM, "Min Chen" <min.chen@citrix.com> wrote:

>Hi Sowmya,
>
>	I still could not understand your statement below about queryAsyncJob 
>api. By searching the codebase, I didn't see anywhere in our code where 
>CS itself triggers this command internally. For example, in deployVMCmd 
>api, which will create an async job and return the job id to user, but 
>CS itself internally will not automatically poll the job result on 
>behalf of the user, so our current implementation will still count this api as 1.
>Did I miss anything here?
>
>	Thanks
>	-min
>
>On 1/30/13 9:39 PM, "Sowmya Krishnan" <sowmya.krishnan@citrix.com> wrote:
>
>>>[Min] Since the intention of this feature is to avoid malicious 
>>>attacks to CS server, we cannot filter out some APIs in throttling control.
>>>Otherwise, Malicious hackers can issue those filtered apis to cause 
>>>CS server down. Also, I don't understand your comment on 
>>>queryAsyncJobResultCmd, why a user cannot really control that? That 
>>>is a user API.
>>
>>You're right queryAsyncJob can be fired independently by user. But I 
>>was wondering in cases where aysnc jobs are issued by users, it 
>>results in multiple queryAsyncJob requests fired (not by the user) 
>>that polls for the job result, and yet, these get counted too although 
>>it was not directly triggered by the user. I would imagine for now, 
>>the solution is to have a sufficiently high api limit so that a user 
>>doesn't encounter the limit too early due to multiple aysnc jobs fired in a short
duration.
>>
>>-----Original Message-----
>>From: Min Chen [mailto:min.chen@citrix.com]
>>Sent: Wednesday, January 30, 2013 11:41 PM
>>To: cloudstack-dev@incubator.apache.org
>>Subject: Re: [DISCUSS]API request throttling
>>
>>Hi Sowmya,
>>
>>	Thanks for the feedback. See my answers inline.
>>
>>	-min
>>
>>On 1/30/13 3:17 AM, "Sowmya Krishnan" <sowmya.krishnan@citrix.com> wrote:
>>
>>>Min, have few questions on this feature while I was coming up with 
>>>test plan -
>>>
>>>1. Do we allow specifying multiple limits based on different 
>>>intervals
>>>- for ex: 10 requests for interval = 5 sec, and 100 for interval = 60 
>>>sec.
>>>Essentially multiple time slices for better granularity and control. 
>>>If yes, how do I set up this?
>>[Min] No, currently we only support specifying one time limit with 
>>your specified interval through components.xml. For the purpose of 
>>avoid malicious attacks to CS server, I don't see the point of 
>>specifying multiple limits for different time slices.
>>
>>> 
>>>2. What is the purpose of resetApiLimitCmd being provided to the User?
>>>Can a user not keep invoking this API and reset his counter every 
>>>time it's exceeding his limit? This should be available only to the 
>>>admin isn't it?
>>[Min] That is the good point, we should only provide reset API to 
>>admin user. I will fix FS to reflect that.
>>
>>>3. Can we have a "negative list" (or a better name) which shouldn't 
>>>be accounted for throttling? For example, queryAsyncJob could be one 
>>>candidate since a user cannot really control that.
>>[Min] Since the intention of this feature is to avoid malicious 
>>attacks to CS server, we cannot filter out some APIs in throttling control.
>>Otherwise, Malicious hackers can issue those filtered apis to cause CS 
>>server down. Also, I don't understand your comment on 
>>queryAsyncJobResultCmd, why a user cannot really control that? That is 
>>a user API.
>>
>>> 
>>>4. FS states the back-off algorithm is TBD. I am assuming it's manual 
>>>for now, at least for 4.1 release?
>>
>>[Min] Yes, that is manual for now.
>>>
>>>Thanks,
>>>Sowmya
>>>
>>>
>>>-----Original Message-----
>>>From: Pranav Saxena [mailto:pranav.saxena@citrix.com]
>>>Sent: Saturday, December 22, 2012 5:20 AM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: [DISCUSS]API request throttling
>>>
>>>A proper error code is certainly seems to be the standard . Just for 
>>>an example , Twitter uses the same for handling their API throttling 
>>>response errors as well  (https://dev.twitter.com/docs/rate-limiting ) .
>>>The back-off algorithm discussion I was referring to was for handling 
>>>automatic  triggering of blocked requests  but I could not think of a 
>>>scenario where it might be useful for cloudstack to have such a
>>>functionality . 	Any ideas /suggestions?
>>>
>>>Regards,
>>>Pranav
>>>
>>>-----Original Message-----
>>>From: Alex Huang [mailto:Alex.Huang@citrix.com]
>>>Sent: Saturday, December 22, 2012 12:51 AM
>>>To: cloudstack-dev@incubator.apache.org
>>>Subject: RE: [DISCUSS]API request throttling
>>>
>>>> 
>>>> 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.
>>>> 
>>>
>>>A proper error code is the right way to do it.  It only makes the 
>>>problem worse if it causes the system to behave poorly so we have to 
>>>design this feature such that processing it doesn't cause 
>>>considerable performance/scale problem in the system.  One 
>>>possibility is a backoff algorithm (saw some discussion about it but 
>>>wasn't sure if it was for this), where we hold off the response if it 
>>>continues to send requests, in effect choking the client.
>>>
>>>--Alex
>>
>


Mime
View raw message